[Freeipa-devel] Draft: Read permissions for user

Martin Kosek mkosek at redhat.com
Thu Apr 24 09:35:58 UTC 2014


On 04/23/2014 10:53 PM, Martin Kosek wrote:
> 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:
>>>>>>>>> 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.
>>
>> 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
>> access.
>>
>> Simo.
>>
> 
> 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.
> 
> Martin

BTW, we already open groups to anonymous - i.e. we might want to keep the same
level of default access to users too.

Martin




More information about the Freeipa-devel mailing list