[Date Prev][Date Next]
Re: (ITS#6468) ACLs in subordinate databases can be ignored
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6468) ACLs in subordinate databases can be ignored
- From: firstname.lastname@example.org
- Date: Wed, 14 Apr 2010 19:16:46 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> 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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/