openldap-bugs September 2015

openldap-bugs@openldap.org

25 participants
81 discussions

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net 22 Sep '15

22 Sep '15

On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert(a)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-rela… Cheers, Ondrej

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

Michael Ströder wrote: > Howard Chu wrote: >> Please use plaintext email only. This thread is mostly unreadable due to the >> multiple escapes and other garbage. >> >> michael(a)stroeder.com wrote: >>> You're talking about QQ (single quote ' mentioned in comment as %x27) an= >>> d QS >>> (back-slash mentioned in comment as %x5C). >>> >>> AFAICS the double quote is %x22 and is included in QUTF1. >> >> Yes, DQUOTE is included in QUTF1 but that is not the issue here. The >> slapd.conf(5) syntax says explicitly that double quote is used to enclose >> arguments containing white space. Single quote has no significance to the >> slapd.conf parser. Arguments containing double quote that are meant to be >> taken literally must escape the quote with a backslash. > > But then I would expect slapd to remove the backslash(es) used for quoting: Good point. OK, there's some more work needed in here somewhere. > > In slapd.conf: > > ---------------------------------- snip ---------------------------------- > attributetype ( 1.3.6.1.4.1.5427.1.389.42.3 > DESC 'Test attribute type with \"double quotes\" in DESC' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > ---------------------------------- snip ---------------------------------- > > Returned via LDAP in subschema subentry (as LDIF): > > attributeTypes: ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with > \"double quotes\" in DESC' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.1 > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Howard Chu wrote: > Please use plaintext email only. This thread is mostly unreadable due to the > multiple escapes and other garbage. > > michael(a)stroeder.com wrote: >> You're talking about QQ (single quote ' mentioned in comment as %x27) an= >> d QS >> (back-slash mentioned in comment as %x5C). >> >> AFAICS the double quote is %x22 and is included in QUTF1. > > Yes, DQUOTE is included in QUTF1 but that is not the issue here. The > slapd.conf(5) syntax says explicitly that double quote is used to enclose > arguments containing white space. Single quote has no significance to the > slapd.conf parser. Arguments containing double quote that are meant to be > taken literally must escape the quote with a backslash. But then I would expect slapd to remove the backslash(es) used for quoting: In slapd.conf: ---------------------------------- snip ---------------------------------- attributetype ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with \"double quotes\" in DESC' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) ---------------------------------- snip ---------------------------------- Returned via LDAP in subschema subentry (as LDIF): attributeTypes: ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with \"double quotes\" in DESC' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.1 Ciao, Michael.

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

Please use plaintext email only. This thread is mostly unreadable due to the multiple escapes and other garbage. michael(a)stroeder.com wrote: > You're talking about QQ (single quote ' mentioned in comment as %x27) an= > d QS > (back-slash mentioned in comment as %x5C). > > AFAICS the double quote is %x22 and is included in QUTF1. Yes, DQUOTE is included in QUTF1 but that is not the issue here. The slapd.conf(5) syntax says explicitly that double quote is used to enclose arguments containing white space. Single quote has no significance to the slapd.conf parser. Arguments containing double quote that are meant to be taken literally must escape the quote with a backslash. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

This is a cryptographically signed message in MIME format. --------------ms030101070905050603070605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >=20 >> On Sep 22, 2015, at 10:37 AM, michael(a)stroeder.com wrote: >> >> Kurt Zeilenga wrote: >>> >>>> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >>>> >>>> Current re24 branch does not accept the following schema description= with double >>>> quote in DESC anymore (which works with 2.4.42) >>> >>> And it shouldn=E2=80=99t, per RFC 4512. >> >> Please be more verbose. >> >> Assuming I'm not mis-reading [1] it allows double quotes in qdstring (= enclosed >> in single quotes). >=20 > You are misreading [1]. the dstring production does not allow the =E2=80= =98 or =E2=80=9C to appear in it. > Instead, \27 is to be used for =E2=80=9C and either \5C or \5c is to be= used for =E2=80=98. You're talking about QQ (single quote ' mentioned in comment as %x27) an= d QS (back-slash mentioned in comment as %x5C). AFAICS the double quote is %x22 and is included in QUTF1. Ciao, Michael. --------------ms030101070905050603070605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMjE4MDIwNFowLwYJKoZIhvcNAQkEMSIEIDB/jT2P8z1vaNnBcy2mGcGUZr6lAPusXEoX FYlfyyEtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBSJuATBusD7rXUx/df xf2W9cpi7HJn787NB3MgvRRB/0qXmhNuG2WnSjw/YwAAtixRr3/tK2MHPXMjVphaEm9hiGqp ZWbHiaIvPoBIUwFeM/ehre0x1N8dhpzuK1RQ2OLPij2RKt+ln7XXQOFNXui+v3wug6xAmsuS AueTxwvNo+Pm1syyDwQsnjJpOItDOSEULkEbJ2PVjkcABnNxhKKyZpr79Kofc4mnvImahNsg SufQ+mTd+IX2ILWsXCtU4GJIYpjAuj7UmkXlT4u5LkHlSj9qy6fxS4oZ4keXFWTqEWm/UxzH pLTQu8ILC8CySC8Z4D6g/QPvumDbCbusQkljAAAAAAAA --------------ms030101070905050603070605--

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

Actually I misread it=E2=80=A6 my bad. I was reading QS as =E2=80=9C for some reason=E2=80=A6. must need more = caffeine. Yes, so DESC =E2=80=98=E2=80=9C=E2=80=98 is a legal qdstring. Sorry for the confusion=E2=80=A6 =E2=80=94 Kurt=

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

> On Sep 22, 2015, at 10:37 AM, michael(a)stroeder.com wrote: >=20 > Kurt Zeilenga wrote: >>=20 >>> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >>>=20 >>> Current re24 branch does not accept the following schema description = with double >>> quote in DESC anymore (which works with 2.4.42) >>=20 >> And it shouldn=E2=80=99t, per RFC 4512. >=20 > Please be more verbose. >=20 > Assuming I'm not mis-reading [1] it allows double quotes in qdstring = (enclosed > in single quotes). You are misreading [1]. the dstring production does not allow the =E2=80=98= or =E2=80=9C to appear in it. Instead, \27 is to be used for =E2=80=9C and either \5C or \5c is to be = used for =E2=80=98. =E2=80=94 Kurt=

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Kurt Zeilenga wrote: > >> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >> >> Current re24 branch does not accept the following schema description with double >> quote in DESC anymore (which works with 2.4.42) > > And it shouldn’t, per RFC 4512. Please be more verbose. Assuming I'm not mis-reading [1] it allows double quotes in qdstring (enclosed in single quotes). [1] https://tools.ietf.org/html/rfc4512#section-4.1 Note that this is not a schema file I've created and which I could change. This is the CIM schema provided as is since years. Ciao, Michael.

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

--Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >=20 > Current re24 branch does not accept the following schema description = with double > quote in DESC anymore (which works with 2.4.42) And it shouldn=E2=80=99t, per RFC 4512. =E2=80=94 Kurt= --Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On Sep 22, 2015, at 12:14 AM, <a = href=3D"mailto:michael@stroeder.com" class=3D"">michael(a)stroeder.com</a> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: auto; word-spacing: = 0px; -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">Current re24 branch does not accept the = following schema description with double</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">quote in DESC anymore (which works with = 2.4.42)</span></div></blockquote></div><div class=3D""><br = class=3D""></div><div class=3D"">And it shouldn=E2=80=99t,  per RFC = 4512.</div><div class=3D""><br class=3D""></div><div class=3D"">=E2=80=94 = Kurt</div></body></html>= --Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be 22 Sep '15

22 Sep '15

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(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2015