[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
ACL processing: subtractive privs (using control continue)
- To: openldap-technical@openldap.org
- Subject: ACL processing: subtractive privs (using control continue)
- From: Dora Paula <deepee@gmx.net>
- Date: Mon, 06 Aug 2012 14:41:46 +0200
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
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
Subtracting "z" results in the access mask "=dxcsr". 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?
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.