Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110410.patch Submission from: (NULL) (2001:4ca0:0:fe11::1) Hi, I'm not quite sure whether the below described scenario can be successfully avoided eg. using current slapd in combination with some kind of tricky ACL configuration statements (if so, any advice is strongly appreciated). Nevertheless, attached below you'll find a small patch that implements a slightly enhanced (aka more restictive!) dnattr acl processing in case of ACL_WDEL operations: In case the currently authenticated user tries to delete his bindDN from the attribute referenced by the dnattr= acl statement, access is denied. Example scenario based on the following (nearly) minimal standard ACL configuration: access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users =w by * none access to dn.onelevel="ou=groups,dc=foo,dc=bar" by dnattr=owner write by * none access to dn.subtree="dc=foo,dc=bar" by users read by * none ... at first a user (user1) successfully creates (add) a new group entry, where/because user1's DN is contained within the entry's owner attribute: OPTS="-Z -D 'uid=user1,ou=users,dc=foo,dc=bar' -w 'user1'" cat <<EOF | ldapadd ${OPTS} dn: cn=test,ou=groups,dc=foo,dc=bar objectClass: groupOfNames objectClass: top cn: test member: cn=otheruser,ou=users,dc=foo,dc=bar description: test group entry owner: uid=user1,ou=users,dc=foo,dc=bar EOF Then, user1 (by mistake but) successfully modifies the just before created and personaly owned entry, deleting his DN from the owner attribute: cat <<EOF | ldapmodify ${OPTS} dn: cn=test,ou=groups,dc=foo,dc=bar changetype: modify delete: owner owner: uid=user1,ou=users,dc=foo,dc=bar EOF As a sideeffect from this second operation user1 has no chance to revert his mistake because he has lost the previous assigned access rights to access this entry by write. In fact nobody else (other than the rootdn) has a chance to correct/delete the dangline group entry. Another disabdvantage of the current implementation is the possibility to move currently managed/owned entries (e.g. users or groups) to other owners/managers without their notice/interaction. The attached patch only interact in case of value delete operations. Thus, based on the patch other owners/managers can be added/deleted as usual (except the DN of the modifyer himself). Added owners/managers can take solely responsibility of an entry by deleting all other owners/managers. I would be very happy in case this patch or at least the based idea could find a way into slapd's code. I don't mind whether this feature is implemented as an extension of current dnattr processing (backward compatibility?) or as an additional configuration option, e.g. "strictdnattr=..." (update documentation?). Also I'm not sure whether set acl statements should or need to be extended into this direction, too... Thank you very much and best regards Daniel
A small but important bugfix for my patch, that also honors access "to all values", can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-20110412.patch
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.
Once again an update of this patch: One more step further dnattr's documented behaviour: Now the DN in dnattr is additionally allowed to remove the whole entry. The update can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110422.patch I'm not quite satisfied with my code and its internal processing. It's more some kind of a prototype. Probably you guys do have the knowlege to "convert" it into a better and slapd-like design... Thanks a lot!
Hopefully nobody else than me has wasted his/her time reviewing my previously submitted patches related to this ITS. They are completely wrong! Here you'll find a rewritten version from scratch which should work as expected or at least can be taken as a basis for further reviewing: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424-2.patch
Hi Howard, as we've discussed during LDAPCon2011's get-together the following idea is currently not supported in slapd. For demonstration purposes I've introduced a <dnattrstyle> that only supports one style-descriptor called ".strict". It restricts "dnattr=..." ACL statements the way that self is not allowed to remove her own DN from dnattr. I've tested the patch with the following simple sample ACLs: to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users write to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,@groupOfNames by dnattr.strict=owner write by users read According these two ACLs a group's owner is allowed to write the whole object (not only add, but also delete, aka in sum "write"). Nevertheless, because of the ".strict" the owner is not able to delete his own DN from the owner attribute. You can find an updated version of my patch here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-111014.patch As it is still intended for demonstration purposes, the patch is highly probable suboptimal regarding its implementation, in particular regarding the chosen place within slapd's code. Instead of the <dnattrstyle> probably a new "<access>" called e.g. "writeToSelfButSelfNoDelete" or similar should be introduced instead. Unfortunately, I don't know how to code this correctly without changing/breaking the whole acl-engine and introducing various "funny" side-effects. Best regards Daniel P.S. Furthermore, and although I've no related scenario in mind, it perhaps could make sense to generalize this kind of behaviour also into direction to "writeToSelfButSelfNoAdd" etc. I'm not sure whether this would make sense, too.
This ITS can be closed. See ITS#7347 instead, currently located http://www.openldap.org/its/index.cgi/Incoming?id=7347;selectid=7347#followup2
See ITS#7347 instead
changed notes changed state Open to Closed