[Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

[Martin Kosek]

On 04/10/2014 02:52 PM, Simo Sorce wrote:
> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
>> On 04/09/2014 12:25 PM, Martin Kosek wrote:
>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote:
>>>> Hello,
>>>> This adds read permissions to read hosts.
>>>>
>>>> Read access is given to all authenticated users.
>>>> For reading host membership info, there is a separate permission that also
>>>> defaults to all authenticated users.
>>>>
>>>> The userPassword attribute is not included for obvious reasons.
>>>
>>> 1) We decided to show hosts only to authenticated users by default. I am just
>>> thinking - should some portion of hosts be readable just like groups and users
>>> are? For example at least the host core defined by nsHost objectlass?
>>>
>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass'
>>>   SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc
>>>   ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )
>>>
>>> Are application supposed to be able to anonymously read that information?
>>
>> I'm not sure. Simo?
> 
> Good question, probably not by default, we offer DNS and do not
> recommend people to rely on exposed host maps.

Question is if should have a separate permission like "System: Read Host Core
Attributes", "System: Read Host", "System: Read Host Membership" or we are fine
with just "System: Read Host", "System: Read Host Membership".

If we do not expect people and programs to often read the list of host or the
basic host information anonymously, I would stick with the latter.

> 
>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read Host
>>> Membership" permission or should it be included in the "Read Hosts" permission?
>>>
>>> If we want to stick with previous behavior, we would want to have only
>>> "memberOf" listed as this is how our original member handling ACI looks like:
>>>
>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost ||
>>> memberUser")(version 3.0; acl "No anonymous access to member information"; deny
>>> (read,search,compare) userdn != "ldap:///all";
>>
>> What was the reasoning behind enrolledBy and managedBy? I got it from 
>> the notes from devconf; I don't think there was much discussion.
> 
> I have no recollection :(

There was no discussion about these particular attributes. I added then to
Membership permission because they were DN-ish, but when I think more about it,
it does not seem as a membership in the sense of the ACI above. I would
personally only keep member/memberOf in the Membership attributes.

>>> 3) I could not functionally test if e.g. clients and replicas still enroll as
>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and
>>> ipa-client-install searches for it.
>>>
>>> Speaking of which, we will need to have an ACI for reading a portion of
>>> krbRealmContainer anonymously to enable IPA client autodiscovery
>>> (cn+objectclass should be sufficient).
> 
> Sad we ended up depending on this, I would have preferred to not depend
> on keeping this around if we ever want to change something.

Yeah... But we should be OK with exposing just the CN which is not really a
secret as we know what is the realm name...

Martin