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