[Date Prev][Date Next]
Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
- From: email@example.com
- Date: Tue, 14 Apr 2009 09:02:25 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> ----- firstname.lastname@example.org wrote:
>> Full_Name: David Markey
>> Version: 2.4.15
>> OS: Debian
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (22.214.171.124)
>> When using a slapo-rwm in conjunction with filter based ACL like
>> access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird"
>> This wont work unless the client explicitly requests the memberOf
>> The client in this case in thunderbird, which doesn't request the
> You should specify the context of your use of slapo-rwm. The limitation
> might not be in the overlay itself, but in your design of the DSA that uses
> slapo-rwm. Unless a more detailed description of the configuration
> highlights a true software bug or design issue, I'm keen to considering
> this a user error.
I chatted with David about this on IRC. The situation is using slapo-rwm on
top of back-relay, pointed at a local (back-bdb) database. He has an ACL in
the relay database using a filter, e.g.:
access to filter=(foo=bar) by * read
In slapo-rwm rwm_attr(), when an explicit list of attributes is requested in a
search, any attributes that weren't requested are stripped from the entry.
Thus, attribute foo disappears if it is not part of the attrs list, and then
the entry cannot be retrieved by the client.
However, if no attr list is specified then slapo-rwm passes the entire entry
through unmolested, and the ACL works.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/