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

[daniel@pluta.biz]

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.