[Date Prev][Date Next]
Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
- From: email@example.com
- Date: Fri, 14 Oct 2011 14:54:02 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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:
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"
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.