[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: child modification

"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.


> 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,


> 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
> 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:

	require write to parent's "children"

	require write to parent's "children"
	AND, if entry acls enabled, write to entry's "entry".

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