rein@OpenLDAP.org wrote:

On 02/02/2010 04:25 PM, Hallvard B Furuseth wrote:

...

Hold on. Is the current behavior self-consistent, i.e. one could call it an undocumented feature? If so someone may have noticed this and written their ACLs accordingly. It's not friendly to change the meaning of existing installations' ACLs in the middle of RE24.

OTOH if current behavior is broken even as a "feature", fix away. E.g. if clients can choose which ACLs will apply in the subordinate by picking a base DN inside vs outside the subordinate.

From my analyzis of the problem, the subordinate ACLs are used in all cases except when syncprov desides which "live" modifications it should replicate to its consumers. Searching with the credentials used by the syncrepl consumer gives me the attributes and entries my subordinate ACLs allows, and they are replicated during the refresh phase. But access to entries and/or attributes being modified during the persistent phase are rejected.

But yes, the change should be analyzed by somebody else before being included in a release.

The fix seems to head in the right direction. One could argue that the correct behavior is to apply the subordinate's ACLs first, and then check the parent's ACLs, and then finally any global ACLs.