Hi list.
I'll try to ask again. :)
We are want use slapd-meta for aggregate several databases to one DIT. We are suppose, users will read and write "o=vega" (virtual) suffix. Members of cn=sysadmins should have write access to all db objects. Also, we would like to use ACL's per-databases, not global.
Currently, write access to ou=devel doesn't work and we can't find error in our acls.
Could somebody help us? We can provide any extended information.
slapd.conf: ... database meta suffix "o=vega" uri ldap://ldap.irka.int.masterhost.ru/ou=devel,ou=sites,o=vega" suffixmassage "ou=devel,ou=sites,o=vega" "ou=devel" uri "ldap://ldap.irka.int.masterhost.ru/o=vega" suffixmassage "o=vega" "o=vega-main" ...
database hdb suffix ou=devel ... access to dn.sub="ou=devel" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,ou=vega-main" write by * read ...
database hdb suffix o=vega-main ...
We are using FreeBSD 7.0 amd64 and openldap-2.4.11
WBR. Dmitriy
Dmitriy Kirhlarov dimma@higis.ru writes:
Hi list.
I'll try to ask again. :)
We are want use slapd-meta for aggregate several databases to one DIT. We are suppose, users will read and write "o=vega" (virtual) suffix. Members of cn=sysadmins should have write access to all db objects. Also, we would like to use ACL's per-databases, not global.
Currently, write access to ou=devel doesn't work and we can't find error in our acls.
run slapd in debugging mode, that is slapd -dacl, to watch acl parsing.
-Dieter
Добрый день.
Dmitriy Kirhlarov dimma@higis.ru writes:
Hi list.
I'll try to ask again. :)
We are want use slapd-meta for aggregate several databases to one DIT. We are suppose, users will read and write "o=vega" (virtual) suffix. Members of cn=sysadmins should have write access to all db objects. Also, we would like to use ACL's per-databases, not global.
Currently, write access to ou=devel doesn't work and we can't find error in our acls.
run slapd in debugging mode, that is slapd -dacl, to watch acl parsing.
-Dieter
I connect to "cn=root on devels hosts,ou=sudoers,ou=devel" as "uid=ishetukhina,ou=users,o=vega".
acl: access to dn.sub="ou=devel" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by * read
"uid=ishetukhina,ou=users,o=vega" is in "cn=sysadmins,ou=groups,o=vega-main"
But I see in log:
Dec 1 18:54:40 ldap slapd[17667]: => acl_mask: access to entry "cn=root on devels hosts,ou=sudoers,ou=devel", attr "entry" requested Dec 1 18:54:40 ldap slapd[17667]: => acl_mask: to all values by "", (=0) Dec 1 18:54:40 ldap slapd[17667]: <= check a_dn_pat: * Dec 1 18:54:40 ldap slapd[17667]: <= acl_mask: [2] applying read(=rscxd) (stop) Dec 1 18:54:40 ldap slapd[17667]: <= acl_mask: [2] mask: read(=rscxd)
Why do [2] work?
Irina Shetuhina irka@masterhost.ru writes:
Добрый день.
Dmitriy Kirhlarov dimma@higis.ru writes:
Hi list.
I'll try to ask again. :)
We are want use slapd-meta for aggregate several databases to one DIT. We are suppose, users will read and write "o=vega" (virtual) suffix. Members of cn=sysadmins should have write access to all db objects. Also, we would like to use ACL's per-databases, not global.
Currently, write access to ou=devel doesn't work and we can't find error in our acls.
run slapd in debugging mode, that is slapd -dacl, to watch acl parsing.
-Dieter
I connect to "cn=root on devels hosts,ou=sudoers,ou=devel" as "uid=ishetukhina,ou=users,o=vega".
acl: access to dn.sub="ou=devel" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by * read
"uid=ishetukhina,ou=users,o=vega" is in "cn=sysadmins,ou=groups,o=vega-main"
But I see in log:
Dec 1 18:54:40 ldap slapd[17667]: => acl_mask: access to entry "cn=root on devels hosts,ou=sudoers,ou=devel", attr "entry" requested Dec 1 18:54:40 ldap slapd[17667]: => acl_mask: to all values by "", (=0) Dec 1 18:54:40 ldap slapd[17667]: <= check a_dn_pat: * Dec 1 18:54:40 ldap slapd[17667]: <= acl_mask: [2] applying read(=rscxd) (stop) Dec 1 18:54:40 ldap slapd[17667]: <= acl_mask: [2] mask: read(=rscxd)
Why do [2] work?
Because the DSA is only authoritative for the Directory Information Tree ou=devel, but not authoritatvie for the DIT o=vega-main, thus cannot check the membership of the group cn=sysadmins, ... Threfor access rule 2 (by * read) is applied.
-Dieter
openldap-software@openldap.org
-
Dieter Kluenter -
Dmitriy Kirhlarov -
Irina Shetuhina