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

Re: ACL processing: subtractive privs (using control continue)



On Aug 6, 2012, at 5:41 AM, Dora Paula <deepee@gmx.net> wrote:

> Hi List,
> 
> just another short question regarding incremental privileges, given the following acl:
> 
> access to dn.subtree="o=test" attrs=description
> by self =dxcsraz continue
> by users -z
> by * none

note that =dxcsraz is results in =wrscxd, because a + z has the same bit set as w.

> Subtracting "z" results in the access mask "=dxcsr".

because the a and z share a bit in each others bit set.   a and z where never designed (or at least not well designed) to be used substractively.

Personally, I think substractive ACLs should be avoided. -, in my opinion, is a misfeature.  Good ACLs should be exact or additive.

> As I expected the resulting access mask to be "=dxcsra", I would like to know whether "=dxcsr" is the correct result, and if so, why?

In this case, I wouldn't even go so far as to say it's the intended behavior.  It's simply the current behavior.  I suspect there's non-obvious design issues here.  That is, there may well be a good reason for why it's coded the way it is.  As with everything with the access control system, I wouldn't consider changing it without very careful analysis and deliberation.

-- Kurt


> 
> Many thanks again!
> 
> 
> A small testbed containing sample ldif data, ldapmodify test command and the produced slapd.log (level 128) follows here:
> 
> sample ldif data:
> ===============
> 
> dn: o=test
> objectClass: organization
> objectClass: top
> o: test
> 
> dn: ou=persons,o=test
> objectClass: organizationalUnit
> objectClass: top
> ou: persons
> 
> dn: cn=PersonA,ou=persons,o=test
> objectClass: person
> objectClass: top
> cn: PersonA
> sn: PersonA
> userPassword:: UGVyc29uQQ==
> 
> 
> test command using ldapmodify:
> =============================
> deepee@test:~$ /opt/openldap-acl/bin/ldapmodify -x -H "ldap://localhost:1389"; -D "cn=PersonA,ou=persons,o=test" -w PersonA <<EOF
> dn: cn=PersonA,ou=persons,o=test
> changetype: modify
> add: description
> description: PersonA1
> EOF
> modifying entry "cn=PersonA,ou=persons,o=test"
> ldap_modify: Insufficient access (50)
> 
> 
> slapd.log level 128:
> =================
> 501fb8b7 => access_allowed: result not in cache (userPassword)
> 501fb8b7 => access_allowed: auth access to "cn=PersonA,ou=persons,o=test" "userPassword" requested
> 501fb8b7 => dn: [1] o=test
> 501fb8b7 => acl_get: [1] matched
> 501fb8b7 => acl_get: [2] attr userPassword
> 501fb8b7 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "userPassword" requested
> 501fb8b7 => acl_mask: to value by "", (=0)
> 501fb8b7 <= check a_dn_pat: self
> 501fb8b7 <= check a_dn_pat: users
> 501fb8b7 <= check a_dn_pat: anonymous
> 501fb8b7 <= acl_mask: [3] applying auth(=xd) (stop)
> 501fb8b7 <= acl_mask: [3] mask: auth(=xd)
> 501fb8b7 => slap_access_allowed: auth access granted by auth(=xd)
> 501fb8b7 => access_allowed: auth access granted by auth(=xd)
> 501fb8b7 => access_allowed: result not in cache (description)
> 501fb8b7 => access_allowed: add access to "cn=PersonA,ou=persons,o=test" "description" requested
> 501fb8b7 => dn: [1] o=test
> 501fb8b7 => acl_get: [1] matched
> 501fb8b7 => acl_get: [1] attr description
> 501fb8b7 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "description" requested
> 501fb8b7 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0)
> 501fb8b7 <= check a_dn_pat: self
> 501fb8b7 <= acl_mask: [1] applying =wrscxd (continue)
> 501fb8b7 <= acl_mask: [1] mask: =wrscxd
> 501fb8b7 <= check a_dn_pat: users
> 501fb8b7 <= acl_mask: [2] applying -z (stop)
> 501fb8b7 <= acl_mask: [2] mask: =rscxd
> 501fb8b7 => slap_access_allowed: add access denied by =rscxd
> 501fb8b7 => access_allowed: no more rules
> 
> 
> 
> BTW: Replacing the first by clause using "self write" or "self =dxcsrw", also results in "=dxcsr"
> JFF: Replacing the second by clause using "users -a", the test results in the above mask (=dxcsr), too.
>