In fact this is the aspected beaviour. What is not espected , to me almost, is that in using the privilege mode in acl processing ( instead of the access level mode) if an access is granted by a previous ace ( by users =s continue in the example) it is possible to have that this access revoked by another ace because this not apply to the actual authenticated user, in this case. This seems to me What it is happening In this case. Should be the access granted only if i use
by users +s continue ( i have not tried yet) ? If yes well it is a little confusing, to me almost.
Best regards
2012/8/5, Kurt Zeilenga kurt@openldap.org:
On Aug 4, 2012, at 9:08 AM, Howard Chu hyc@symas.com wrote:
Dora Paula wrote:
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.
I haven't looked at the code yet but it's possible this is a bug.
Not a bug. As documented, every access statement ends implicitly with a "by
- none" clause.
-- Kurt
Please submit an ITS with your explanation and sample config/ldif.
Thanks again.
Regards
2012/8/4, Dora Pauladeepee@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 behavior.
Attached you'll find my minimalistic testbed: slapd.conf sample ldif data two ldapsearch commands (including their slapd.log level 128)
I'm using openldap MASTER.
Thank you very much.
Cheers Dora
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/