On 04/23/2014 08:07 PM, Simo Sorce wrote:
On Wed, 2014-04-23 at 18:19 +0200, Martin Kosek wrote:
On 04/23/2014 05:21 PM, Simo Sorce wrote:
On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote:
On 04/17/2014 01:45 PM, Petr Viktorin wrote:
On 04/16/2014 03:41 PM, Simo Sorce wrote:
On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote:
On 04/15/2014 04:55 PM, Petr Viktorin wrote:
At Devconf, we decided what most of the default read permissions should look
like, but we did not get to user.
Here is a draft of 4 read permissions. Please comment.

Basic info (anonymous):
      cn, sn, description
      displayName, givenName, initials

<== We originally specifically hidden memberOf attribute from anonymous users.
I think we should continue hiding it.


      gecos, gidNumber, homeDirectory, loginShell, uidNumber

Details (all authenticated):
      seeAlso, telephoneNumber
      fax, l, ou, st, postalCode, street
      destinationIndicator, internationalISDNNumber,
          postalAddress, postOfficeBox, preferredDeliveryMethod,
          registeredAddress, teletexTerminalIdentifier, telexNumber,
      carLicense, departmentNumber, employeeNumber, employeeType,
          preferredLanguage, mail, mobile, pager
      audio, businessCategory, homePhone, homePostalAddress, jpegPhoto,
          labeledURI, o, photo, roomNumber, secretary, userCertificate,
          userPKCS12, userSMIMECertificate, x500UniqueIdentifier
      inetUserHttpURL, inetUserStatus

I would personally not divide the attributes as basic and detailed. IMO it is
our artificial distinction and may vary between deployments. Why would we for
example show inetUserHttpURL to authenticated only and ipaSshPublicKey to

I thought it would be helpful to have a distinction between what needs
anonymous read, and what's optional.

I know, my point was that I would leave this distinction to FreeIPA admins as
the visibility to anonymous/authenticated will depend on their policies. I
would create stricter rules only about attributes we are sure about, like the
ones below.

If some admin wants to hide some attribute, removing it from our user
permission and adding a user read permission for authenticated users is very
simple, I do not think the second permission needs to be managed.

I can move individual attributes, of course.

My proposal would be to have a permission "Read User Information" for all
attributes above.

This way a paranoid admin would need to go through the attributes one by one to
decide what needs to stay anonymous and what doesn't. Having two permissions
makes this easier to tune.

But of course I can merge them.

I am not sure how is that simpler. If admin does not like an attribute being
open for authenticated and not for anonymous, he would need to remove it first
from authenticated permission and add it to anonymous permission.

I am personally for having all attributes above (except memberOf) open for
anonymous. Rob or Simo, are you OK with it?

I am for exposing them only to authenticated users.


To clarify - you want to have one permission allowing all attributes above
(except memberOf) to authenticated users? Note that previously we exposed user
data to anonymous so it would be a functional change.

I know, we may need to provide another permission admins can use to turn
on anonymous searches for those attributes too.
We may also decide that on upgrade vs new install we retain anonymous


That permission is called

$ ipa permission-mod "System: User Information" --bindtype all

This is all that's needed to make all the user attributes above readable by authenticated users and not by anonymous.


Freeipa-devel mailing list

Reply via email to