[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ACL processing: additive privs (using control continue)
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 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
>>>>> 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/
>>
>
>
--
Inviato dal mio dispositivo mobile