(ITS#6900) dnattr acl statement: users can produce dangling entries

[daniel@pluta.biz]

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