[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACL inconsistency -- groups and sets



David Pisoni wrote:
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.
-----------------------------------------------------------------------------