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
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to