[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.
>