Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays

[masarati@aero.polimi.it]

andres@anarazel.de wrote:
> This is a multi-part message in MIME format.
> --------------080405020304060402030808
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit

Your analysis looks correct.  In fact, the uniqueness check for add 
seems to assume that the current entry will implicitly match the 
uniqueness filter, which may not be the case if an additional filter is 
provided within the URI.

> Fixing this for unique_add seams easy enough (see preliminary attached 
> patch) - fixing it for modrdn/modify seems to be another difficulty 
> level as in order to properly apply the filter I think the full 
> modifications have to be applied...
> 
> If wanted I can produce a patch for this as well, but I would like to 
> know if that is appreciated and if my plan for fixing looks sensible:
> - Pull the "modification simulation" code out of constraint.c (line 
> 959:1040 and some more in 2.4.16) into constraints.c
> - Add a overlay-int.h
> - Make constraint.c and unique.c use that
> 
> As I dont really know the openldap codebase my analysis could be 
> completely wrong - I would appreciate some feedback.

Yes, the code provided in the constraint overlay is exactly intended to 
simulate the modification in order to be able to assess the consistency 
of the resulting entry with the constraint.

What you suggest sounds reasonable; a patch would definitely be welcome. 
  The code extracted from constraint.c should probably be placed in 
slapd, and always built since other portions of slapd might need it in 
the future.  Please note that overlays can be selectively built, or even 
built as modules, so creating cross-dependences is not a good idea IMHO.

p.