Re: gidNumber uniqueness

[Ferenc Wagner <wferi@niif.hu>]

Michael Ströder <michael@stroeder.com> writes:

> Ferenc Wagner wrote:
> 
>> We use (among others) this unique domain in a database:
>> 
>> olcUniqueURI: ldap:///?gidNumber?sub?objectClass=posixGroup
>> 
>> so that we can't create two groups with the same gidNumber.  The problem
>> is that this rule also denies the creation of a posixAccount belonging
>> to an already existing posixGroup.  Of course there is no problem
>> creating the account first and the group later.  How could we overcome
>> this ordering limitation?
>
> This is a bug in slapo-unique ignoring the filter part:
>
> http://www.openldap.org/its/index.cgi?findid=6825
>
> You can work around this if your group entries all reside in a separate
> subtree and you use the DN portion in the olcUniqueURI value.

Hmm, now that you pointed this out, I find these two paragraphs of
slapo-unique(5) contradictory:

  Uniqueness is enforced by searching the subtree to ensure that the
  values of all attributes presented with an add, modify or modrdn
  operation are unique within the scope.  For example, if uniqueness
  were enforced for the uid attribute, the subtree would be searched for
  any other records which also have a uid attribute containing the same
  value. If any are found, the request is rejected.

This does not seem to apply the filter to the object being added,
matching the behaviour observed by me.

  The filter component causes the domain to apply uniqueness constraints
  only to matching objects.  e.g.  ldap:///?cn?sub?(sn=e*) would require
  unique cn attributes for all objects in the subtree of the back-end
  database whose sn starts with an e.

This says that the filter is applied to the object being added, which
makes more sense and would result in sensible behaviour.

So let me ask for clarification: which interpretation is the indended
and the implemented one?
-- 
Thanks,
Feri.