[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACL processing: additive privs (using control continue)

Iiuc, your acl permit search ( There are any entries of question type
in term of search filter) to any authenticated user. If the user is
also member of the group grant also read privilege ( give me the
entries question type) .

That's what I've expected, too, and what is the standard behavior if you use "users" continued by "self" for example.

In case of a continued groupdn evaluation the behavior changes:

If the current bindDn is not a member of the group or the group's entry does not exist the previously granted search privilege (=s) is reset: The aclmask gets reset to =0 which means "none". Please have a look into the attached details (file "acl.txt" in my previous posting).

My question was: Is this the intended behavior? I would have expected the search privileges to stay untouched, even in case the group's entry does not exist.

Thanks again.


2012/8/4, Dora Paula<deepee@gmx.net>:
Hi list,

just a short question about "continue" and additive privileges, given
the following acl statement:

access to dn.subtree="o=test" attrs=sn
   by users =s continue
   by group/groupOfNames/member="cn=readers,ou=groups,o=test" +r

If the current user's bindDn isn't a member of the group
"cn=readers,..." or the group's entry does not exist, the previously set
privilege "=s" will be reset to "none"?

As the slapd.access man page just gives a "silly" and an "even more
silly" example regarding "continue" I'm not sure this is the intended

Attached you'll find my minimalistic testbed:
    sample ldif data
    two ldapsearch commands (including their slapd.log level 128)

I'm using openldap MASTER.

Thank you very much.