Full_Name: Kartik Subbarao Version: 2.4.23 OS: Debian Linux 5.0.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.99.175.5) I have the uniqueness overlay configured as follows in slapd.conf: overlay unique unique_uri ldap:///?gidNumber?sub?(objectClass=posixGroup) The policy I want to enforce is that all posixGroup entries must have a unique gidNumber attribute. At the same time, I want to *allow* non-posixGroup entries (such as inetOrgPerson) to have the same gidNumber attribute that a posixGroup entry has. This is so that a user can have a login group id set to that of an existing group. With the above configuration in place, if I create a posixGroup entry with gidNumber 389, and then try to add a gidNumber attribute of 389 to an inetOrgPerson entry, the operation fails with a constraint error "some attributes not unique". As I read the manpage for slapo-unique, the unique_uri filter seems to support the functionality that I want: ===== 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. ===== I'm inferring from this that uniqueness constraints on the cn attribute would *not* be applied to objects that don't match the filter. But that doesn't seem to be happening here. Is this a bug in the uniqueness overlay or am I not understanding the implementation?
One clarification -- in my original message, I meant to say "posixAccount" in place of "inetOrgPerson". These are inetOrgPerson objects, but they also have the posixAccount objectClass which allows them to have the gidNumber attribute. -Kartik
subbarao@computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.23 > OS: Debian Linux 5.0.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.99.175.5) > > > I have the uniqueness overlay configured as follows in slapd.conf: > > overlay unique > unique_uri ldap:///?gidNumber?sub?(objectClass=posixGroup) > > The policy I want to enforce is that all posixGroup entries must have a unique > gidNumber attribute. At the same time, I want to *allow* non-posixGroup entries > (such as inetOrgPerson) to have the same gidNumber attribute that a posixGroup > entry has. This is so that a user can have a login group id set to that of an > existing group. > > With the above configuration in place, if I create a posixGroup entry with > gidNumber 389, and then try to add a gidNumber attribute of 389 to an > inetOrgPerson entry, the operation fails with a constraint error "some > attributes not unique". > > As I read the manpage for slapo-unique, the unique_uri filter seems to support > the functionality that I want: > > ===== > 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. > ===== > > I'm inferring from this that uniqueness constraints on the cn attribute would > *not* be applied to objects that don't match the filter. But that doesn't seem > to be happening here. Is this a bug in the uniqueness overlay or am I not > understanding the implementation? Looks like a bug, the filter check is only implemented for Add operations, not for Modify or ModDN. In the meantime, as a workaround you should simply use a more fully qualified URI. Restrict the URI to the ou containing your posixGroup entries. Since user names and group names are separate name spaces in POSIX, you cannot store them both in the same branches of a DIT anyway. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 02/03/2011 06:24 PM, Howard Chu wrote: > Looks like a bug, the filter check is only implemented for Add > operations, not for Modify or ModDN. > > In the meantime, as a workaround you should simply use a more fully > qualified URI. Restrict the URI to the ou containing your posixGroup > entries. Since user names and group names are separate name spaces in > POSIX, you cannot store them both in the same branches of a DIT anyway. The workaround works, thanks for the quick response! There will be other uniqueness scenarios where it will be good to have the full functionality, but for this situation we should be fine. Regards, -Kartik
moved from Incoming to Software Bugs
Hi, This bug is still present in 2.4.44. Also, it seems to be the same bug as bug #6077. Regards Yann Soubeyrand
See also ITS#6077
changed notes
modify fixed in HEAD; modrdn needs work modify fixed in RE24; modrdn needs work