Hi, it's me again,
with another small but also very important bugfix for the previous two versions of my patch. This patch does not change the correct (as documented by the project) behaviour of "dnattr=... selfwrite". It can be found here:
ftp://ftp.openldap.org/incoming/Daniel-Pluta-110415.patch
FYI and the log: Next to some simple always reproducible test-shellscripts (ldapmodify add/delete distinct values) I have been also using Apache Directory Studio to test and workout the intended behavior of my ACLs, which is the root cause for these two updates: I've not been aware of the difference between "to value" and "to all values", yet and all my testcases (ldif changetype modify) only have been using "to value" operations.
I've used following ACL to test this second patch of my original patch:
access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users read by * none
access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description by users read by * none break
access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member by dnattr=member selfwrite by * none
Based on these ACL each user that is a member of a group entry seems to be just the only member of these group (from the user's point of view, in case the user accesses the group's member attribute by read). When using Apache Directoy Studio to delete this only/single/last group member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation.
=> acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr "member" requested => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)
It seems to me that this appears to be a bug in ADS, where the client (ADS) tries to be more inteligent/comfortable/strict than needed. OTOH based on this strange behaviour I've learned something "new" (and quite important to me in regard to acl design and testcases during testing). Sorry for these kind of SPAM and the circumstances. Hopefully that's the last bugfix for that patch.