[Date Prev][Date Next]
Re: slapd-meta and acls
Irina Shetuhina <email@example.com> writes:
> ÐÐÐÑÑÐ ÐÐÐÑ.
>> Dmitriy Kirhlarov <firstname.lastname@example.org> 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
>>> 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
> I connect to "cn=root on devels hosts,ou=sudoers,ou=devel" as
> 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: => acl_mask: access to entry "cn=root on devels hosts,ou=sudoers,ou=devel", attr "entry" requested
> Dec 1 18:54:40 ldap slapd: => acl_mask: to all values by "", (=0)
> Dec 1 18:54:40 ldap slapd: <= check a_dn_pat: *
> Dec 1 18:54:40 ldap slapd: <= acl_mask:  applying read(=rscxd) (stop)
> Dec 1 18:54:40 ldap slapd: <= acl_mask:  mask: read(=rscxd)
> Why do  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 KlÃnter | Systemberatung
GPG Key ID:8EF7B6C6