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: >>>>>> Hello, >>>>>> 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): >>>>>> [top] >>>>>> objectclass >>>>>> [person] >>>>>> cn, sn, description >>>>>> [organizationalPerson] >>>>>> title >>>>>> [inetOrgPerson] >>>>>> uid >>>>>> displayName, givenName, initials >>>>>> manager >>>>>> [inetUser] >>>>>> memberOf >>>>> >>>>> <== We originally specifically hidden memberOf attribute from anonymous >>>>> users. >>>>> I think we should continue hiding it. >>> >>> OK >>> >>>>>> [ipaObject] >>>>>> ipaUniqueID >>>>>> [ipaSshUser] >>>>>> ipaSshPubKey >>>>>> [ipaUserAuthTypeClass] >>>>>> ipaUserAuthType >>>>>> [posixAccount] >>>>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber >>>>>> >>>>>> >>>>>> Details (all authenticated): >>>>>> [person] >>>>>> seeAlso, telephoneNumber >>>>>> [organizationalPerson] >>>>>> fax, l, ou, st, postalCode, street >>>>>> destinationIndicator, internationalISDNNumber, >>>>>> physicalDeliveryOfficeName, >>>>>> postalAddress, postOfficeBox, preferredDeliveryMethod, >>>>>> registeredAddress, teletexTerminalIdentifier, telexNumber, >>>>>> x121Address >>>>>> [inetOrgPerson] >>>>>> carLicense, departmentNumber, employeeNumber, employeeType, >>>>>> preferredLanguage, mail, mobile, pager >>>>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, >>>>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, >>>>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier >>>>>> [inetUser] >>>>>> inetUserHttpURL, inetUserStatus >>>>>> [ipaUser] >>>>>> userClass >>>>> >>>>> 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 >>>>> everyone? >>> >>> 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. > > Simo. >
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. Martin _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
