--- Comment #15 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
On Thu, Apr 08, 2021 at 08:12:18PM +0000, openldap-its(a)openldap.org wrote:
The attached patch contains a test script which, I believe, validates
the (newly but not yet fully documented in the patch) access rules which
are required to bind.
thanks for the patch. I don't understand many of the assertions below
and don't understand what the test script is supposed to test, if you're
saying it uncovers bugs, does it mean if fails for you? I doesn't fail
for me even if I uncomment/enable parts that look like they're
However, I believe I have uncovered another bug. It appears that,
even when every access rule applies _only_ to a single DIT entry,
one attribute of that entry, and grants access to _only_ a single DN,
the access rules are sensitive to ordering. Some access rules are
required, given a particular ordering of the access rules, that are
not required when the rules are re-ordered.
ACLs are order-sensitive, could you give an example?
Search for "ORDERING BUG" in the test script for an
code there is run twice, once with an authz-regexp with a URI and
again with an authz-regexp that does direct DN mapping with a regexp.)
Again, this doesn't fail for me and nothing there suggests what the
alternative set up should be to make it expose a bug.
The supplied test case does not test every permutation of the given
access rules, which leaves open the possibility that it is not
discovering all the access rules that are required; and the supplied
documentation patch does not mention any ordering requirements for
access rules and so is likely incomplete.
I don't believe that access rules should be order dependent unless,
obviously, there exist some rules that apply to the same portion of
the DIT and also grant access to more than one authenticating entity.
Could you give an explicit example?
P.S. Work on the test case is what uncovered bug# 9495.
I wound up using a ":" character in the authzid
to work-around the problem, and made corresponding
adjustments to the authz-regexp(s). When 9495
is fixed you may want to fiddle with the test script
and do "something different"; or not.
If you consider the authzid provided by the client has to go through
normalisation as per RFC4513 Section 188.8.131.52, would you comment on
ITS#9495 whether/or to what extent it might explain your findings?
You are receiving this mail because:
You are on the CC list for the issue.