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.