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.
I'm not really familiar with sets, but let me try to answer: when you do DN substring matching in ACLs, you're simply playing with substrings of the DN from a regex point of view; when you use sets, on the contrary, you're playing with the contents of the entry they aplly to, so in the first case all the children of the entry you're matching have o=<smtg> in their DN, while only the dn: o=<smtg>,... actually holds that "o" value. You're doing a completely different sort of match.
I guess you need to do something else to mtch portions of the DN in a set, or try to rework your ACLs to achieve the same goal.
Pierangelo.
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
-- Dr. Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it LDAP Architect, SysNet s.n.c. http://www.sys-net.it
----------------------------------------------------------------------------- Chi riceve il presente messaggio e` tenuto a verificare se lo stesso non gli sia pervenuto per errore. In tal caso e` pregato di avvisare immediatamente il mittente e, tenuto conto delle responsabilita` connesse all'indebito utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso contenute, voglia cancellare l'originale e distruggere le varie copie o stampe. The receiver of this message is required to check if he/she has received it erroneously. If so, the receiver is requested to immediately inform the sender and - in consideration of the responsibilities arising from undue use and/or disclosure of the message and/or the information contained therein - destroy the original message and any copy or printout thereof. -----------------------------------------------------------------------------