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?

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.

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

We can wait with the functional testing until you get to krbRealmContainer 
though.

Yes, it's still quite early for functional testing.


--
PetrĀ³

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to