Re: Modifications to support ModifyDNRequest (LDAP v3): comments?

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

At 04:01 PM 1/20/99 -0800, Juan Carlos Gomez wrote:
>Just wanted to bounce this through your minds to make sure I am not
>missing anything.

I've a conn->c_protocol which should be appropriately checked.
Currently it's 0 until the client succesfully binds then is
updated with the version provided in the bind.

Per the v3 spec, if any operation is done before the
bind, v3 should be assumed.  However, to be compatible
with existing implementations I rather not assume it's a v3
client until they do something non-U-Mich'ish (like supplying
a newSuperior).

If 2, then it is an error to provide a newSuperior.
If 3, okay.
If 0, okay but set it to 3.

Of course, to test this, you'll need to anonymously do the
dn rename as our bind returns an error if the protocol is not v2.

I'll try to add in the v3 (simple) bind support in soon.

>in -----> ldap/servers/slapd/modrdn.c:
>
>1.-Need to check for presence of the newSuperior parameter in the
>request
>and "ber_scanf" if it exists.
>2.-Need to pass the newSuperior parameter to the modrdn of the related
>backend.

>in ----->ldap/servers/slapd/back-* (those that support modrdn):
>
>1.-Receive new superior as a parameter from the caller.
>
>2.-Change Parent DN in accordance to newSuperior parameter.

NO!  The rename only applies to the entry specified by the dn.
You must:
 - do all basic modrdn checks (is leaf).
 - check to see if 'newSuperior' exists (if not, error)
 - check to see if 'newSuperior' is current parent or the entry itself
	(if so, error).
 - check to see if 'newrdn, newSuperior exists (if so, error)
 - add the entry to the under the newSuperior
 - adjust the entry's DN
 - remove the entry from the oldSuperior
 - update various indexes

then:
>3.-If (deleteoldrdn==TRUE), need to "attr_delete(_by_val)" the old rdn
>component from the entry.

Yes, this should be added for the simple modrdn case as well.
I recommend doing this first as a warm up.

>4.-Need to add new rdn as an attribute to the affected entry.

Yes.

You need to make sure the ACLs are correct. To rename an dn, the
bound dn should have write privs both the current parent's
(oldSuperior) and new parent's (newSuperior) "children" attribute.

Also, be very careful with the entry r/w locks.  modrdn
already locks the entry and its parent.  Then you'll
have to lock the newSuperior.  There's an obvious dead-lock
sitituation there which we'll have to avoid (likely by requiring
modrdn to obtain a per-backend 'rename' lock BEFORE it acquires
any other lock).

ldap_rename is likely the most difficult operation to implement
correctly.  However, don't let that stop you...

Kurt