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.
--On Monday, September 14, 2015 8:38 AM +0000 geert@hendrickx.be wrote: > 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. Hi Geert, Per discussion with Howard & Halvard, The rationale was that manageDSAit means let me operate on the raw data and disable all side-effects. This is still correct and should remain. However, an option could be added to the module to disable this control specifically for this overlay. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
quanah@zimbra.com wrote: > Per discussion with Howard & Halvard, > > The rationale was that manageDSAit means let me operate on the raw data and > disable all side-effects. This is still correct and should remain. > However, an option could be added to the module to disable this control > specifically for this overlay. Why not just change to use the Relax Rules Control instead? Especially since it already requires manage privilege. Which use-case would not work anymore when using Relax Rules Control instead of manageDSAit control? Do you expect any unwanted side-effects? IIRC the Relax Rules (formerly known as Manage DIT) control was simply not yet invented when Pierangelo implemented this. Ciao, Michael.
On Mon, Sep 21, 2015 at 12:28:35 -0700, Quanah Gibson-Mount wrote: > The rationale was that manageDSAit means let me operate on the raw data and > disable all side-effects. This is still correct and should remain. For clarity I do agree that a control should exist to bypass uniqueness (and other) constraints. However I think manageDSAit is not the appropriate control by its definition, and also in practice given the fact it's set per default by popular client libs. Relax Rules seems much more appropriate for this use case, as it's intended to temporarily relax database constraints, for administrative use only. > However, an option could be added to the module to disable this control > specifically for this overlay. No, then I would need to change the server config to disable that option each time I'd wish to temporarily bypass the constraint, instead of using another dedicated control for that (which would need no disable option). Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert@hendrickx.be wrote: > On Mon, Sep 21, 2015 at 12:28:35 -0700, Quanah Gibson-Mount wrote: > > The rationale was that manageDSAit means let me operate on the raw data and > > disable all side-effects. This is still correct and should remain. > > For clarity I do agree that a control should exist to bypass uniqueness > (and other) constraints. However I think manageDSAit is not the > appropriate control by its definition, and also in practice given the > fact it's set per default by popular client libs. > > Relax Rules seems much more appropriate for this use case, as it's intended > to temporarily relax database constraints, for administrative use only. Yes, Relax control is better for manual bypass. We just need to make sure the original issue that this code was created to address is not reintroduced. ITS#6641 was put up to allow replication to bypass this overlay and anything that was already loaded to one master should happily replicate everywhere else. At that point, manageDSAit was the only way I could find to distinguish an operation coming from syncrepl, it seems that the constraint overlay has a more reliable check so that might be a better idea. Patch to that effect is here: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150922-ITS-8245-unique-relax.patch Cheers, Ondrej
On Tue, Sep 22, 2015 at 08:45:12PM +0000, ondra@mistotebe.net wrote: > On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert@hendrickx.be wrote: >> For clarity I do agree that a control should exist to bypass uniqueness >> (and other) constraints. However I think manageDSAit is not the >> appropriate control by its definition, and also in practice given the >> fact it's set per default by popular client libs. >> >> Relax Rules seems much more appropriate for this use case, as it's intended >> to temporarily relax database constraints, for administrative use only. > > Yes, Relax control is better for manual bypass. We just need to make > sure the original issue that this code was created to address is not > reintroduced. ITS#6641 was put up to allow replication to bypass this > overlay and anything that was already loaded to one master should > happily replicate everywhere else. At that point, manageDSAit was the > only way I could find to distinguish an operation coming from syncrepl, > it seems that the constraint overlay has a more reliable check so that > might be a better idea. > > Patch to that effect is here: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150922-ITS-8245-unique-relax.patch Given that relax control is still allowed for everyone (and no ACL support for controls exists yet), this patch will buy us little. I have updated the test suite accordingly so that this can be merged when OpenLDAP is ready: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330-ITS-8245-unique-relax.patch -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ondra@mistotebe.net wrote: > Given that relax control is still allowed for everyone (and no ACL > support for controls exists yet), this patch will buy us little. Please correct if I'm wrong but AFAIK you need 'manage' privilege to circumvent constraints (e.g. slapo-constraint and slapo-ppolicy). Ciao, Michael.
On Thu, Mar 30, 2017 at 05:13:47PM +0200, Michael Ströder wrote: > ondra@mistotebe.net wrote: >> Given that relax control is still allowed for everyone (and no ACL >> support for controls exists yet), this patch will buy us little. > > Please correct if I'm wrong but AFAIK you need 'manage' privilege to circumvent > constraints (e.g. slapo-constraint and slapo-ppolicy). You don't need to be granted ACL_MANAGE to bypass slapo-constraint. Just your providing -e '!relax' will do. Just that some features and operations (add/rename) are protected by an additional ACL_MANAGE check if you run with the relax control so they will fail unless you have that privilege. I guess there is some room in the interpretation of what draft-zeilenga-ldap-relax-01 says: "[it is] expected that use of this extension will be restricted by administrative and/or access controls" One options is that if you specify the control, especially since you have to make it critical, you should qualify for administrative permissions on that operation or have it fail regardless of whether it would ordinarily succeed. If OpenLDAP backends adhered to that reading, constraint would do the right thing now and unique would as well with the patches I provided. The other reading is "using relax might let you do more, but you still need the right permissions", which is closer to how manageDSAIt works and it seems that's what OpenLDAP (but not slapo-constraint) does. The hassle is that you need to check permissions if you want to follow that and that's hard to do correctly if you're an overlay. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ondra@mistotebe.net wrote: > The other reading is "using relax might let you do more, but you still > need the right permissions", which is closer to how manageDSAIt works > and it seems that's what OpenLDAP (but not slapo-constraint) does. The > hassle is that you need to check permissions if you want to follow that > and that's hard to do correctly if you're an overlay. AFAIK using Relax Rules control makes slapd finish a write operation in case a constraintViolation would be returned without this control provided the bound identity has manage privilege (and of course does not hit insufficientAccess before because of missing write privilege). IMO slapo-unique should do the very same. If the behaviour is unclear I'd hack a test configuration. Ciao, Michael.
has patch
changed notes
Created attachment 633 [details] Ondrej-Kuznik-20150922-ITS-8425-unique-relax.patch
Created attachment 634 [details] Ondrej-Kuznik-20170330-ITS8245-unique-relax.patch
(In reply to Michael Ströder from comment #6) > Please correct if I'm wrong but AFAIK you need 'manage' privilege to > circumvent constraints (e.g. slapo-constraint and slapo-ppolicy). That doesn't appear to be the case. A user with only 'write' privilege can actually use Relax to modify attributes freely, bypassing slapo-constraint. Personally I find this behaviour quite surprising. I would have expected both overlays to behave like slapo-unique does (Relax honoured only with manage access). As an administrator, configuring an overlay such as slapo-constraint seems fairly pointless if users can simply ignore it any time they choose. I don't understand the global Relax handling for Add/Rename, but not Modify, either. If I understand the two options Ondřej described, either we should require manage access _always_ in the presence of Relax, or only if the request actually needs some rules to be relaxed. But AFAICT neither of those is (consistently) the case right now... (I guess this gets rather off-topic for this ticket, sorry!)
Commits: • 6d6a3300 by Ondřej Kuzník at 2020-04-06T20:44:09+00:00 ITS#8245 Use Relax control to avoid uniqueness checks Still needs to retrieve the entry for ACL resolution until we can restrict controls with ACLs
head: • 81b5ca91 by Ondřej Kuzník at 2022-06-14T21:52:18+00:00 ITS#8245 Do not try to release a NULL entry RE26 (2.6.3): • 85649edf by Ondřej Kuzník at 2022-06-23T18:34:57+00:00 ITS#8245 Do not try to release a NULL entry RE25 (2.5.13): • c8059b5d by Ondřej Kuzník at 2022-06-23T18:46:44+00:00 ITS#8245 Do not try to release a NULL entry