Re: child modification

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

"Efgé" wrote:
> > 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.
> Okay, so I'll expand a bit on what I need :

Thanks.  The detail did help.

> If you follow the unix analogy, what I'd like is a directory
> like /tmp which has rights rwxrwxrwt, t meaning only the owner can delete it.

A file in such a directory, of course, is also removable by the owner of the
directory as well...  However, I think we've taken this analogy (like most)
a bit too far.

> The entries can be created by any admin. Once created, the person
> is assigned to that manager and only this manager is allowed to change
> the entry, or remove it. The manager can also shift administration of
> this person to another manager by changing the "manager" attribute.

Off topic: one drawback to your approach is that you have to rely
on rootdn to deal with orphaned entries (entries with an invalid manager
or no manager).

> But with the standard setup, as any admin can create an entry, any admin
> would also be able to delete any entry, which is unacceptable.

Okay.  

> Now you'll ask, why didn't I use subtrees.

No, I won't.  Subtrees are not for everyone.

> Don't you agree that having everything "flat" is much simpler in
> this setup,

Yes.

> and that SLAPD_CHILD_MODIFICATION_WITH_ENTRY_ACL is exactly what I require ?

Well, I agree that the current "children" mechanism isn't enough in this
situation and that some varient of the "entry" acl approach might be a suitable
solution.  However, there may be other solutions which may be better.

> > Another issue is that administrators may forget to restrict
> > access to this attribute and unknownly grant rename privs to
> > their users (self write).
> 
> Surely misconfiguration is not a valid reason for restricting
> the available options ?

Actually it is!  We have a number of options which are purposely
restricted.  However, they are restricted in the sense that extra
steps are needed to enabled them.  However, they are still available.

> > In general, it's better to implement a policy using ACLs than to let
> > ACLs define your policy.
> 
> Yes, and I had defined my policy as outlined above, only the ACLs
> wouldn't let me do it, so I was about to change the code when I saw
> the SLAPD_CHILD_MODIFICATION_WITH_ENTRY_ACL define, and here I am.
>
> Well, does this make any sense at all ?

Yes.  Before making "entry" ACLs a configurable option, I like to:
	1) review other options
	2) look at ways of integrating "entry" ACLs which protect
		against misconfiguration

Here's one slight varient which might work out okay:

 add:
	require write to parent's "children"

 modrdn/delete:
	require write to parent's "children"
	AND, if entry acls enabled, write to entry's "entry".

 rename:
	require write to old and new parent's "children"
	AND, if entry acls enabled, write to entry's "entry".

Comments?