Re: rs_modlist for modRDN

[Luke Howard <lukeh@padl.com>]

>In fact, the problem was there, but it only appeared in test006 when you
>added the SLAP_MOD_INTERNAL to the naming attribute modifications; this
>flags essentially causes ACLs to be skipped for those modifications.

Sorry for my slopiness.

Just one thing to watch out for: if a SLAPI preoperation plugin changes
the modification list, any instances of sml_flags will be lost, because
the interface forces modifications to be passed as LDAPMods.

Right now, this probably only affects the password policy overlay (the
other use of SLAP_MOD_INTERNAL is in slap_mods_opattrs(), which is
called from the backend). But it could also affect future code or user
provided overlays when combined with SLAPI preoperation plugins.

Possible solutions include attempting to restore sml_flags when calling
slapi_pblock_set() (by comparing with the old list) or moving sml_flags
into some unused bits of sml_op.

<rant>
The use of LDAPMod, instead of an opaque type with accessor functions,
is IMO the most unfortunate design decision in SLAPI. This was kind of
addressed with the Slapi_Mod type (which I haven't yet implemented for
OpenLDAP) but the SLAPI_MODIFY_MODS parameter remains LDAPMods as it is
difficult to change without breaking backwards compatibility. Were it
not for this SLAPI would probably be a reasonably portable (and
efficiently implementable) plugin API for all sorts of X.500-like
directory servers.
</rant>

-- Luke

--