(ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?

[geert@hendrickx.be]

Full_Name: Geert Hendrickx
Version: 2.4.42
OS: 
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.123.14.2)


Currently the ManageDsaIt control allows bypassing attribute uniqueness
constraints as implemented by slapo-unique(5).  This seems inappropriate as the
ManageDsaIt control (RFC 3296) is intended for managing referral objects.  Also
it is set by default by certain clients (specifically Java JNDI) which makes
uniqueness constraints practically useless with such clients.

The newer Relax Rules control (draft-zeilenga-ldap-relax) seems much more
appropriate for this use case, please consider using it instead.  The simple
pchch below works for me, but I haven't tested its interaction with
replication.


	Geert


--- servers/slapd/overlays/unique.c     2015-08-14 17:25:28.000000000 +0200
+++ servers/slapd/overlays/unique.c     2015-09-07 22:00:44.217833199 +0200
@@ -1038,9 +1038,8 @@
        Debug(LDAP_DEBUG_TRACE, "==> unique_add <%s>\n",
              op->o_req_dn.bv_val, 0, 0);
 
-       /* skip the checks if the operation has manageDsaIt control in it
-        * (for replication) */
-       if ( op->o_managedsait > SLAP_CONTROL_IGNORED
+       /* skip the checks if the operation has relax control in it */
+       if ( op->o_relax > SLAP_CONTROL_IGNORED
             && access_allowed ( op, op->ora_e,
                                 slap_schema.si_ad_entry, NULL,
                                 ACL_MANAGE, NULL ) ) {
@@ -1170,9 +1169,8 @@
        Debug(LDAP_DEBUG_TRACE, "==> unique_modify <%s>\n",
              op->o_req_dn.bv_val, 0, 0);
 
-       /* skip the checks if the operation has manageDsaIt control in it
-        * (for replication) */
-       if ( op->o_managedsait > SLAP_CONTROL_IGNORED
+       /* skip the checks if the operation has relax control in it */
+       if ( op->o_relax > SLAP_CONTROL_IGNORED
             && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on)
== LDAP_SUCCESS
             && e
             && access_allowed ( op, e,
@@ -1301,9 +1299,8 @@
        Debug(LDAP_DEBUG_TRACE, "==> unique_modrdn <%s> <%s>\2222,
                op->o_req_dn.bv_val, op->orr_newrdn.bv_val, 0);
 
-       /* skip the checks if the operation has manageDsaIt control in it
-        * (for replication) */
-       if ( op->o_managedsait > SLAP_CONTROL_IGNORED
+       /* skip the checks if the operation has relax control in it */
+       if ( op->o_relax > SLAP_CONTROL_IGNORED
             && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on)
== LDAP_SUCCESS
             && e
             && access_allowed ( op, e,

--- doc/man/man5/slapo-unique.5 2015-08-14 17:25:28.000000000 +0200
+++ doc/man/man5/slapo-unique.5 2015-09-14 09:22:26.242624918 +0200
@@ -162,7 +162,7 @@
 maximum flexibility in meeting site-specific requirements.
 .LP
 Replication and operations with
-.B manageDsaIt
+.B relax
 control are allowed to bypass this enforcement. It is therefore important that
 all servers accepting writes have this overlay configured in order to maintain
 uniqueness in a replicated DIT.