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
Sorry for the top posting.
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) .
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
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.
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
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. 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
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/
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/
Kurt Zeilenga wrote:
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.
Ah right. The "continue" control is only useful if a following "by" clause matches the subject *and* specifies incremental privileges.
Howard Chu wrote:
Kurt Zeilenga wrote:
On Aug 4, 2012, at 9:08 AM, Howard Chuhyc@symas.com wrote:
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.
Ah right. The "continue" control is only useful if a following "by" clause matches the subject *and* specifies incremental privileges.
Any following "by" clause specifying a group pattern obviously can also specify incremental privileges *and* can (unforeseeable) match the subject.
Group entries and their members tend to be independent. Neither the existence of a distinct group's entry nor its members are known in advance (for example during slapd acl configuration time). Furthermore existing group entries as well as memberships disappear without prior notice. - In general groups are managed by people that aren't and usually don't need to be aware of slapd's internal acl engine dependencies. - Modifying a group (e.g. removing members or the entry) that is referenced within an acl probably results in the need to modify the belonging "by" clauses. - Statically pre-initializing all group entries referenced in the acls is misleading especially regarding the idea behind variable groups and memberships. - ...
Thus, resetting previously given privileges just in case a group pattern temporarily does not match seems to overshoot or even miss the target, especially in case the group entry or the member exists/disappears/exists/... during runtime.
My suggestion regarding a basis to start a hopefully fruitful discussion is: Within "by" clauses using group patterns and specifying incremental privileges the final implicit "by * none" should be ignored (or at least be made ignoreable) for the current access-statement, while the controls stay untouched (attached you'll find a prototype of a patch). If the idea is acceptable, stable's behavior can be changed in general or smoothly for example by introducing some kind of groupDn evaluation specifier to make the evaluation of group pattern specific incremental privileges customizable (ignoreable), e.g. "group[/<objectclass>[/<attrname>]][.<groupstyle>][,<evalspecifier>]=<group>".
<evalspecifier> ::= "ignoreNoSuchObject" | "ignoreCompareFalse" | "ignoreBoth" ...
The location of such an <evalspecifier>, e.g. at the groupDn specifier, within the by clause, within the access clause or even globally is intentionally left open here.
Another (at least to me much better) solution seems to be to get rid of the implicit "by * none" code: It represents neither a reasonable security functionality, nor a valueable convenience feature - the opposite seems true: Implicit (hidden) "security" hides mission critical settings and functionallity, causes headache that leads to misinterpretation that can result in wrong asumptions (not only for beginners, even for experts, see above). The (need for) discussion represents just one sign for the inconvenience caused by such a kind of "convenience feature". With cn=config a missing "by * none" (as any other) acl statement can be added during runtime without the past time (slapd.conf) need to restart slapd. Although the implicit "by * none" seems outdated, specifying adequate frontend acls "implicit (but documented in the configuration) by * none" has been already achievable for some time in the past until today.
In case of an "unwilling to perform situation", lets just try to get rid of the two useless ("silly" and the "even more silly") continue control examples described in slapd.access(5), either by - Describing a appropriate "clever" continue example or if this should be generally impossible, by - Removing the obviously silly continue control code, or eventually by - Starting a (openldap-devel?) discussion whether and if so, how to integrate the above described (or similar) generally useful feature.
Thank you very much.
On Aug 5, 2012, at 1:58 PM, Dora Paula deepee@gmx.net wrote:
Another (at least to me much better) solution seems to be to get rid of the implicit "by * none" code: It represents neither a reasonable security functionality, nor a valueable convenience feature - the opposite seems true: Implicit (hidden) "security" hides mission critical settings and functionallity, causes headache that leads to misinterpretation that can result in wrong asumptions (not only for beginners, even for experts, see above). The (need for) discussion represents just one sign for the inconvenience caused by such a kind of "convenience feature". With cn=config a missing "by * none" (as any other) acl statement can be added during runtime without the past time (slapd.conf) need to restart slapd. Although the implicit "by * none" seems outdated, specifying adequate frontend acls "implicit (but documented in the configuration) by * none" has been already achievable for some time in the past until today.
I find your argument to be a bit stretched.
First, what you actually suggest is to REPLACE the implicit rule with another implicit rule. So your argument that implicit rules are bad would equally apply to "by +none stop" as it applies "by =none stop". And what you asking for is simply a convenience, you don't want to add the "by +none stop" yourself.
While if we were designing the ACL system today I might have chosen something else, that's not what we're doing. The only time this change would have been reasonable to make was when additiive/substructive ACLs where added. And, IIRC, we actually discussed making the change at that time and that we concluded leaving the default by clause as it was for years before was best.
Now some years latter, changing the default would be a really bad idea as that may well change the evaluation of deployed ACLs.
As far as your more complex suggestion, I think it's overly complex. What I would want to see before it (or any change to ACLs) be even considered is a clear description of the use case, an clear explanation as to why the current ACL system cannot met the use case without change, and how the change preserves evaluation of existing deployed ACLs. That's something better discussed on the devel list.
-- Kurt
Am 06.08.2012 03:57, schrieb Kurt Zeilenga:
On Aug 5, 2012, at 1:58 PM, Dora Paula <deepee@gmx.net mailto:deepee@gmx.net> wrote:
Another (at least to me much better) solution seems to be to get rid of the implicit "by * none" code:
So your argument that implicit rules are bad would equally apply to "by +none stop" as it applies "by =none stop". And what you asking for is simply a convenience, you don't want to add the "by +none stop" yourself.
I've not been aware of the possibility to override (neutralize) the <who> clause lists implicit termination using the in/decremental neutral element "+none". I've not tested it yet, but I think that's fine. Thanks for your explaination. Please forget the rest for now.
Perhaps an extension of the slapd.acces(5) with one sentence that just mentions this possibility makes sense?
openldap-technical@openldap.org
-
devzero2000 -
Dora Paula -
Howard Chu -
Kurt Zeilenga