Re: uniqueness constraint violated when using ldapadd -M

[Geert Hendrickx <geert@hendrickx.be>]

On Tue, Aug 25, 2015 at 15:12:22 +0200, Geert Hendrickx wrote:
> On Tue, Aug 25, 2015 at 13:46:09 +0100, Howard Chu wrote:
> > Geert Hendrickx wrote:
> > >Hi,
> > >
> > >I noticed uniqueness constraints enforced by the slapo-unique overlay can
> > >be bypassed when using the manage DSA IT control (ldapadd -M).
> > 
> > >The uniqueness constraint has been violated when using -M, while it was
> > >correctly enforced without -M.
> > >
> > >Feature or bug?
> > 
> > RTFM, this is already explicitly documented in the slapo-unique(5) manpage.
> > 
> 
> 
> 
> Thanks, I overlooked that.  I'm not managing the LDAP client here, I'll
> have to talk to the devs why they are using the ManageDsaIt control.


It's still not clear for me what is the link between the Manage DSA IT
control and uniqueness constraint.  From RFC 3296 defining the control:

   A control, ManageDsaIT, is defined to allow manipulation of referral
   and other special objects as normal objects.  As the name of control
   implies, it is intended to be analogous to the ManageDsaIT service
   option described in X.511(97) [X.511].

   [...]

   In the presence of a ManageDsaIT control, referral objects are
   treated as normal entries as described in section 3.  Note that the
   ref attribute is operational and will only be returned in a search
   entry response when requested.

   In the absence of a ManageDsaIT control, the content of referral
   objects are used to construct referrals and search references as
   described in Section 4 and, as such, the referral entries are not
   themselves visible to clients.


Why must it bypass the uniqueness constraints on the server?


	Geert


-- 
geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!