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.