Re: LDAP extensions for subtrees.

[Bruce Greenblatt <bgreenblatt@dtasi.com>]

John,

Thanks for the feedback.  This intention of the draft is that the SOS
operations are to have the same end result as if the LDAP client had
submitted a stream of standard LDAP operations.  So, you can't delete
objects to which you don't have access.  So, if I have the DIT:

                       O=ABC
                      /    \
                 OU=A       OU=B
                 /         /     \
                /         /       \
            OU=X      OU=Y      OU=Z
              |
            CN=B

Assume that I don't have access to OU=X, OU=A, O=ABC, but I do I have
access to OU=A, O=ABC and OU=B, O=ABC.  If I try to copy OU=A, O=ABC over
underneath OU=B, O=ABC, then the only object that would get copied would be
the OU=A, O=ABC object, since I don't have access to the rest of the
subtree.  Similarly, If I tried to delete the OU=A, O=ABC subtree, I would
not be successful for the reasons that you point out.  If I'm blocked at
any point in the delete subtree operation, then those objects beneath that
access point, and above it to the root of the target subtree are not
deleted.  I think that partial subtree deletions in this scenario may be
appropriate.

Bruce

At 11:45 AM 6/21/99 -0700, John Merrells wrote:
>
>Bruce Greenblatt wrote:
>> 
>> Here's a little draft that I wrote that describes some extended operations
>> that work against subtrees in LDAP.  In attempting to build LDAP
>> applications requirements for copying, modifying and deleting subtrees come
>> up repeatedly.  These types of operations are most effectively performed by
>> LDAP servers atomically, rather than by LDAP clients through the use of the
>> standard LDAP operations.  So, see:
>> http://search.ietf.org/internet-drafts/draft-greenblatt-ldapext-sos-00.txt,
>> or another I-D repository near you...
>
>Copy...
>
>If access control prevents a parent entry from being read... are the children
>copied? This would violate the ldap constraint that every entry much have a
>parent. In LDUP terms the copy is a sparse replica.
>
>If access control prevents some attributes from being copied, the resultant
>copy of the entry may violate the schema.
>
>The filter, just as access control, can create a sparse replica of the
subtree.
>
>Delete...
>
>If access control prevents the deletion of an entry then it's parents entries
>up to the root will remain. But, if the operation were atomic then shouldn't
>all other entries not be deleted too?
>
>
>John
>
>
>