Re: child modification

["Efgé" <efge@mail.dotcom.fr>]

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

Basically our setup is a database of people's mail addresses.
There are several administrators that deal with this database, because
people are using different pop3 servers and thus are assigned addresses
by different people.

here are my rules:

# this uses SLAPD_CHILD_MODIFICATION_WITH_ENTRY_ACL
### password
access to dn=".*,o=Gouv,c=FR"
       attrs=userpassword
        by self                 write
        by dnattr=manager       write
        by addr=127.0.0.1       compare
	by dn=.*		none
### Admins
# add
access to dn="ou=Admin,ou=Education,o=Gouv,c=FR"
       attrs=children
        by dnattr=manager       write
        by addr=127.0.0.1       read
        by dn=.*                none

# delete, rename and modify
access to dn="[^,]*,ou=Admin,ou=Education,o=Gouv,c=FR"
        by dnattr=manager       write
        by addr=127.0.0.1       read
        by dn=.*                none

### Mail entries
# new entries
access to dn="ou=Adc,ou=Education,o=Gouv,c=FR"
       attrs=children
        by dn="cn=[^,]*,ou=Admin,ou=Education,o=Gouv,c=FR"      write
        by dnattr=manager                                       write
        by addr=127.0.0.1       read
       by dn=.*                none
# delete, raname and modify by the manager
access to dn="[^,]*,ou=Adc,ou=Education,o=Gouv,c=FR"
        by dnattr=manager       write
        by addr=127.0.0.1       read
        by dn=.*                none

In this setup, everything is stored in a single level as children of
ou=Adc,ou=Education,o=Gouv,c=FR

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.

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, with each subtree belonging
to an administrator which does what it wants with its entries ?
Two reasons:
 - with this second setup, when you create an adminstrator you'd also have
   to create the start of the subtree for this administrator ;
 - when you want to move an entry from one administrator to another, it
   involves BOTH of them which is cumbersome.
   Besides moddn doesn't seem to exist in 1.2.1 and modrdn is buggy
   and has cache coherency problems.


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 ?



> The old "entry" attribute approach had numerous shortcomings.  The
> largest in my eyes is that it doesn't restrict the renamer to particular
> subtrees.

Well, it does if you only use modrdn which is the only thing I have
access to in 1.2.1

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

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.

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


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



Florent