https://bugs.openldap.org/show_bug.cgi?id=9256
--- Comment #15 from Ondřej Kuzník <[email protected]> --- On Thu, Apr 08, 2021 at 08:12:18PM +0000, [email protected] 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, -- You are receiving this mail because: You are on the CC list for the issue.
