[Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts
Simo Sorce
simo at redhat.com
Thu Apr 10 12:52:24 UTC 2014
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.
> > 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 :(
> > 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.
> > We can wait with the functional testing until you get to krbRealmContainer though.
>
> Yes, it's still quite early for functional testing.
--
Simo Sorce * Red Hat, Inc * New York
More information about the Freeipa-devel
mailing list