[Issue 9634] New: ACL processing of <what> clauses should evaluate regex pattern after other variants
https://bugs.openldap.org/show_bug.cgi?id=9634
Issue ID: 9634 Summary: ACL processing of <what> clauses should evaluate regex pattern after other variants Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: michael@stroeder.com Target Milestone: ---
Evaluating regex patterns cost performance.
Thus cheaper <what> parts (e.g. attrs=) should be evaluated before dn.regex= and val.regex=. Likely evaluating simple dn.(sub|one|exact) should be split from processing dn.regex.
https://bugs.openldap.org/show_bug.cgi?id=9634
--- Comment #1 from Michael Ströder michael@stroeder.com --- Or ideally <what> clauses should be processed in the order they appear in the config source instead of a hard-coded order.
https://bugs.openldap.org/show_bug.cgi?id=9634
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- On Sun, Aug 15, 2021 at 10:46:16PM +0000, openldap-its@openldap.org wrote:
Or ideally <what> clauses should be processed in the order they appear in the config source instead of a hard-coded order.
In that case, storing them in a list, we wouldn't really be able to limit the <what> clauses to one per type. Suggesting an extension to the ACL syntax to allow the same type of <what> clause to occur multiple times in a rule, I'm not sure what the semantics of that should be.
https://bugs.openldap.org/show_bug.cgi?id=9634
--- Comment #3 from Michael Ströder michael@stroeder.com --- 1. Even when storing <what> clauses into a list you could maintain a separate bit field which types are already defined and reject multiple <what> clauses of same type during config parsing.
2. You could also simply treat <what> clauses of same type with and-relation. This could be useful in some cases. E.g. define a cheap <what> DN clause for skipping an irrelevant ACL more early in most cases but ensuring to only fire after applying all potentially expensive checks.
-
openldap-its＠openldap.org