[Freeipa-devel] Read access to container entries

[Simo Sorce]

On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote:
> Hi Petr,
> 
> we already discussed on IRC, but see some comments below
> On 03/28/2014 04:11 PM, Petr Viktorin wrote:
> > Hello,
> > I'm trying to add ACIs to allow read access to containers, and I need 
> > some input.
> >
> > The DS's access control system is not designed to allow access to a 
> > single entry but not its descendants. The [ACI documentation] suggests 
> > some ways to work around it.
> >
> > This doesn't work that well for read access in IPA:
> >
> > $SUFFIX needs anonymous read access; ipa-client-install looks for 
> > "info=IPA V2.0" anonymously.
> > cn=accounts,$SUFFIX needs read access if it or any of its children are 
> > to be listed in a GUI
> > cn=users,cn=accounts,$SUFFIX needs read access if it or any users are 
> > to be listed in a GUI
> > uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied
> >
> > It's safe to expose IPA's default containers anonymously; all they 
> > tell the user is that they're looking an IPA server.
> >
> > The container entries themselves just have cn and an objectClass of 
> > cnContainer, so it's impossible to construct a general targetfilter 
> > that targets them but not any possible descendants.
> >
> > I see 3 possible solutions:
> > 1) File a DS RFE to implement [targetscope]. With that we could have 
> > ACIs that only target a single entry, so admins could manage read 
> > access to containers in the usual way (with permissions).
> > 2) Add a (objectClass=nsContainer) filter. The problem here is that if 
> > this is on cn=accounts,$S, it would also affect e.g. 
> > cn=users,cn=accounts,$S, and other nsContainers under it. For example, 
> > cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer.

Re-reading this I am not sure I understand the example, the filter
wouldn't apply to masters as they are under cn=etc not cn=accounts

I guess you meant that if we set the permission on the root in order to
see accounts that we also show masters and other parts of the tree?
(like hbac and sudo ..

> > 3) Add a special attribute to mark "public" containers, and add an ACI 
> > with a filter on that. Something like objectClass=ipaPublicContainer 
> > would do.
> there is one more option
> 4) add an allow aci for cn=accounts,$S and a deny aci for 
> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S

We want to get rid of deny ACIs if at all possible.

> In general I think we should implement 1), there will be other scenarios 
> where it could be useful. If something is needed imemdiately I would 
> also prefer 3)

I wonder, can we have an objectclass that defines no attributes ?
Or do we always need to have a MAY at least ?

Anyway I agree that the simplest solution would be to have an
objectclass to filter on.

But I see 2 options.
1. objectClass=ipaPublicContainer
2. objectClass=ipaPrivateContainer

The problem with the second is adding a
(!(objectclass=ipaPrivateContainer)) everywhere ...

> >
> >
> > I'm thinking about 3, but I'd like to ask an LDAP expert for opinions.
> >
> >
> > Note that children can be accessible even if the parent isn't. This 
> > whole container business only affects exploring the DIT with a GUI-ish 
> > tool.
> >
> 


-- 
Simo Sorce * Red Hat, Inc * New York