https://bugs.openldap.org/show_bug.cgi?id=9256
--- Comment #14 from Karl O. Pinc kop@karlpinc.com --- 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.
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.
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.)
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.
If you (openldap) agree with the assessments above I leave it to you to continue to develop the test case. Say, by having the script test all permutations of rule ordering.
Further, if there is indeed a bug to fix, code alterations could well affect the permissions required to bind. For these reasons, and because I've spent far too much time on this to-date, I would like to back-away from further development of this patch. I am willing to continue to assist with the wording of the documentation when you have determined that the time is right.
There remains work on the documentation portion of the patch. I don't see a lot of point in proceeding until it is known if the test script is comprehensive.
I have not fully annotated all the access rules in the test script, referencing them back to the portion of the documentation that says they are required. These annotations should shed light on any further changes, as below, that the documentation needs.
I believe that text must be added to the documentation which says that access to objectClass is not required (for sasl binds) in the case of proxy authorization.
I believe that text must be added to the documentation which says that sasl binds need =x by the authorizing identity on "entry" of the search base of authzFrom URIs (but not when dn mapping). (In addition to =x access by "anonymous", which is documented.)
I believe that text must be added to the documentation which says that sasl binds need =x by the authorizing identity on the authFrom attribute of the authorized identity when authFrom contains a URI (but not when dn mapping). (In addition to =x access by "anonymous", which is documented.)
I believe that text must be added to the documentation which says that sasl binds via an authorizing group need anonymous to have access to "entry" of the authorizing entity. (Attention needs to be paid here to the relationship between this requirement and the authz-regexp.)
I believe that text must be added to the documentation which says that simple binding with dn.onelevel does not need "cn" access by authorizing entity. But my notes don't say which of the dn.onelevel tests this applies to.
Regards,
Karl kop@karlpinc.com Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
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.