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