[Date Prev][Date Next]
Re: (ITS#3497) Enhancement: back-sql and non-leaf operations
- To: email@example.com
- Subject: Re: (ITS#3497) Enhancement: back-sql and non-leaf operations
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Thu, 20 Jan 2005 07:50:04 -0800
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <200501201502.j0KF2JdA004485@boole.openldap.org>
- References: <200501201502.j0KF2JdA004485@boole.openldap.org>
[moved to devel for broader discussion]
At 07:02 AM 1/20/2005, firstname.lastname@example.org wrote:
>Full_Name: Pierangelo Masarati
>Submission from: (NULL) (126.96.36.199)
>Back-sql could be easily modified to support operations on non-leaves, like
>subtree deletion e.g. when the LDAP_CONTROL_X_TREE_DELETE is used, and renaming
>of non-leaf entries, thanks to the transaction support of the underlying RDBMS.
What would you do if you run into an referral object?
Is there any implementation of MS's tree delete (in OpenLDAP?
in non-MS server?). Seems the specification is incomplete...
>Subtree deletion would require to fetch all the children, check whether there's
>any referral among them (which would require manageDSAit for the entire
>operation?) and subsequent deletion.
I don't see this as something requiring manageDSAit (control
I do see it requiring permission to delete each object in
>Renaming would be even easier, since only table ldap_entries would require to be
>modified (essentially, all subtree DNs need be renamed, and that's all). I
>guess manageDSAit would yet be required if there's any referral among the
>children, so all entries should be fetched in any case.
>I'm wondering if any special permission should be requested for operations
>of this kind. Maybe manageDSAit, possibly with the extra 'm' (manage)
>access to the baseObject of the operation (see followups on -devel of
For rename, same permission as if the entry to be moved had no
children. (See back-hdb)
For delete tree, see above.