Re: (ITS#5884) disclose ACL not safe on non-leaf objects

[andrew.findlay@skills-1st.co.uk]

On Mon, Jan 12, 2009 at 07:47:20PM +0000, hyc@symas.com wrote:

> > For example, if I have a DIT like this:
> >
> > dc=example,dc=org--+
> >                     +--dc=a--+
> >                     |        +--dc=people--+
> >                     |                      +--cn=a1
> >                     |
> >                     +--dc=b--+
> >                              +--dc=people--+
> >                                            +--cn=b1
> >
> > and I give read access on dc=example,dc=org (base)
> > and on dc=a,dc=example,dc=org (subtree)
> > and dc=people,dc=b,dc=example,dc=org (subtree)
> > but no access at all on dc=b,dc=example,dc=org
> > then I would not expect to be able to read the cn=b1 entry, as doing so would
> > expose the existence of dc=b.
> >
> > What actually happens is that any attempt to read dc=b itself returns
> > correctly as if the entry does not exist, but a simple subtree search
> > happily returns cn=b1.
> 
> Which is the natural outcome of granting read access to the dc=people subtree.
> 
> If you want the server's behavior to make sense, then give it ACLs that make 
> sense.

Agreed - for some value of "sense" :-)

I simplified the example to the minimum that would demonstrate the
behaviour, so it may seem like an odd thing to do in the first place.

There are several possible reasons to want a non-discoverable entry
to block discovery of entries beneath it. One example would be an
organisation that is preparing to open a new department: it needs
to populate the department data with entries carrying the access
markers that will be used in production, but have the whole lot
remain invisible to users and applications until everything is
ready. The obvious way to implement this is to use access-control
to make the root of the new subtree non-discoverable, but it only works
if the non-discoverability extends to the whole subtree. This is
effectively the scenario that I described in the ITS.

I want to make the discoverability of entries dependent on the value of
an attribute in a parent node, but I cannot see a way of doing it using
the existing ACL syntax and behaviour.

The closest I have got so far is to use the set syntax in a deny rule:

# Blockers - look for exampleVisibility=block in all parent entries
#
access to *
        by set="this/-*/exampleVisibility & [block]" none
        by * break

This allows any entry to block its subtree to *all* users by setting 
exampleVisibility=block
There does not seem to be any way to make the block dependent on
*who* is requesting access, as sets are only valid in the 'by <who>'
part of the rule.

Something like this might work if sets could be used in the <what> part:

access to set="this/-*/exampleVisibility & [internet]"
	attrs="entry,children"
	by * read

access to set="this/-*/exampleVisibility & [users]"
	attrs="entry,children"
	by users read

Ah - no it would not work, as it would permit read if *any* superior
entry permits read. I want to be sure that *all* superior entries
permit read. Foiled again!

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------