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(a)gmx.net&gt;: -- Inviato dal mio dispositivo mobile

Dora Paula wrote: 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. -- -- 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(a)openldap.org&gt;: -- Inviato dal mio dispositivo mobile

Howard Chu wrote: 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.

Am 06.08.2012 03:57, schrieb Kurt Zeilenga: 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?