https://bugs.openldap.org/show_bug.cgi?id=9256
--- Comment #15 from Ondřej Kuzník ondra@mistotebe.net --- On Thu, Apr 08, 2021 at 08:12:18PM +0000, openldap-its@openldap.org wrote:
Hello,
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.
Hi Karl, 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 (temporarily) disabled.
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 example. (The 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 5.2.1.8, would you comment on ITS#9495 whether/or to what extent it might explain your findings?
Thanks,