[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