RE: ACL inconsistency -- groups and sets

[David Pisoni <dpisoni@lrn.com>]

Forgive me for "beating my own drum", but I was wondering if anyone at all
could shed some light on this?  I'm confused as to why the set functionality
would behave so differently.

Thanks,
David

-----Original Message-----
From: David Pisoni [mailto:dpisoni@lrn.com]
Sent: Tuesday, October 22, 2002 11.19
To: 'OpenLDAP-software@openldap.org'
Subject: ACL inconsistency -- groups and sets


Hello,

I have encountered an odd inconsistency in the ACL processing.  Here is the
problem configuration:

------------------
# Base ACL
access to *
	by self write
	by users read break
	by anonymous auth

# Trouble ACL
access to dn="o=(.*),ou=Clients,dc=lrn,dc=com"
	by group="cn=Admin,ou=Groups,o=$1,ou=Clients,dc=lrn,dc=com" write
	by set="user/o & this/o" read
------------------

The group ACL works as expected -- a member of "cn=Admin,ou=Groups"
groupOfNames under the particular matched "o=.*" entry is granted write
access to said "o=.*" entry and all its descendants.
The 'set' ACL does not work as expected -- a matching user (one in which "o"
matches the target "o=.*" entry) is granted read access to said "o=.*"
entry, but *none* of its descendants.  (In a perfect world, I would use the
$1 in the set clause, but it doesn't look like set supports interpolating
target matches.)

I can only assume the 'set' ACL processing is attempting to test the match
for every descendant (and since none of the descendants have an "o"
attribute, the match fails.) But the 'group' ACL processing isn't being so
explicit in its matching -- matching the parent is enough.  Why the
discrepancy?

(Yes, I know that this scheme is a security hole unless the "o" attribute is
carefully protected.)

Thanks,

David Pisoni
Sr. Software Engineer,
LRN, The Legal Knowledge Company
dpisoni@lrn.com
310-209-5364