Re: child modification

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

The basic child ACL logic can be summarized as follows:

Add/Moddn(modrdn)/delete: permission to create, rename, delete requires
 write access parent's "children" attribute.

Compare/Modify/Search: normal entry ACLs

This, in my opinion, is fairly clean and less likely to create
security issues.

The old "entry" attribute approach had numerous shortcomings.  The
largest in my eyes is that it doesn't restrict the renamer to particular
subtrees.  That is, if given the right to rename, I can rename it
under any parent.  The "children" approach resolves this be requiring
you to have permission to write access to both the old and new parents.
(analogous to moving a file between directories in Unix).

Another issue is that administrators may forget to restrict
access to this attribute and unknownly grant rename privs to
their users (self write).  A user could abuse rename privs
to gain greater accesses than desired (by renaming her entry
such that different ACLs apply).

At 11:06 PM 4/27/99 +0200, Florent Guillaume wrote:
>I use the SLAPD_CHILD_MODIFICATION_WITH_ENTRY_ACL definition and find it
>extremely useful (because we have several administrators on the same
>tree, and once an entry has been created only the same administrator
>should be able to modify/delete it -- only SLAPD_CHILD_... enables me to
>do this).

I think you should be able to do this using children attribute,
groups, and/or (ab)using the 'creatorsname' operational attribute.
However, before attempting to write such ACLs, I'd suggest you
write up a brief access policy.  In general, it's better to
implement a policy using ACLs than to let ACLs define your policy.

>Or do you have other plans for that feature ?

Per commit comments, the "entry" attribute ACLs is
deprecated and subject to eventual removal.  I'm willing
to leave the code in the distribution if folks are
using (and maintaining) it.

>I was wondering if you would accept a patch to make it a slapd.conf
>option?

I think it would be wise to determine if current mechanisms
can support your needs.  If they cannot, then we should
discuss how best to provide the desired functionality.

>I'll write the patch if you find it's a good idea.

I don't know if it's a good idea or not (yet)...  additional
discussion is needed.

Kurt