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

Re: rename across trees: manageDIT?

Kurt D. Zeilenga wrote:

ManageDIT is not intended to allow administrators to do anything
they please.  It's intended to more easily work around some
DIT constraints.  For instance, if the admin wants to add some
attribute whose type is currently marked obsolete (e.g., inactive),
the admin could temporarily mark the schema as active, add
the attribute, then mark the attribute type obsolete again.
The manageDIT operation allows those three operations to be
condensed into one operation, and in doing so, avoid nasties
of having the type temporary active.

Likewise for structualObjectClass.  The admin could delete and
re-add the object to accomplish a change in structural object
class.  ManageDIT allowed condensing the delete+add into a

LDAP requires the DIT to be in a consistent state after each
update (add, delete, modify, rename).  ManageDIT allows
other constraints to be lifted during the processing of the
operation, but the basic DIT consistency requirement must
still hold.

One can argue that UUID/CSNs should be mucked with as
doing so can create inconsistencies. I haven't much problem
allowing UUIDs to be updated (as long as we don't find any
(replication or other) issue in allowing this, but obviously
allowing CSN updates would be problematic. (Directory
applications should be using timestamps not CSNs...
which, BTW, one good reason for DSAs to use CSNs in replication.)

One issue I'm finding is that when modifications get to access checking, noUserMod attrs are mixed with the others. So I'm considering the opportunity to extend the Modifications structure to host a managing flag that's on when the attribute is being managed. This allows to decide whether a modification should be checked for access.

Another issue I'm seeing is that if I do an "add" with some of the manageable attributes provided (again in the spirit of synthesizing operations: I could do a regular add, followed by a modify that manages attrs, but I don't want the entry to appear until it's managed), "manage" access is not checked for each attribute, but only for the entry. Is this acceptable? I mean: check for "manage" access for the entire entry as soon as at least one attribute is managed?


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497