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

[Petr Viktorin]

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

Let's do that then. It's easy enough to add a custom permission.

>>>> 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.

Moved to Read Host.

>>>> 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
>


-- 
Petr³
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0506.2-Add-managed-read-permissions-to-host.patch
Type: text/x-patch
Size: 1794 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140410/a00c48f1/attachment.bin>