- openldap-bugs - openldap.org

(ITS#7260) problem with 2.4.30 to 2.4.31 upgrade
by ato＠iem.pw.edu.pl 24 Apr '12

24 Apr '12

Full_Name: Andrzej Tobola Version: 2.4.31 OS: FreeBSD 9.0 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.29.146.94) I run slapd from a long time on FreeBSD stable amd64 and it is started with args: slapd -4 -h "ldapi://%2fvar%2frun%2fslapd.socket ldap://localhost/ ldap://ldap2/ ldaps://ldap2/" -u ldap -g ldap After upgrade from 2.4.30 to 2.4.31 my server can't start: slapd[29221]: read_config: no serverID / URL match found. Check slapd -h arguments. Nothing was change in en environment - only ldap was upgraded. After backing-off only this one commit to bconfg.c: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=b4d4… all is working again. Any clue ? and IHMO this message shod be more informative for casual user.

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com 24 Apr '12

24 Apr '12

Hello, this was not fixed entirely. > ftp://ftp.openldap.org/incoming/jvcelak-20120223-0002-man-add-SASL_NOCANON-… SASL_NOCANON option is still missing in ldap.conf(5). Jan

1 0

Re: (ITS#7259) Ppolicy count bytes not characters
by michael＠stroeder.com 24 Apr '12

24 Apr '12

This is a cryptographically signed message in MIME format. --------------ms090008060908020301080505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jiri.Netolicky(a)cdt.cz wrote: > Slapo-ppolicy manual page says: > pwdMinLength: ..this attribute contains the minimum number of charact= ers that > will be accepted in a password >=20 > But it seems that the code not chcount number of characters but number = of bytes. I guess this is because attribute type userPassword is declared with LDAP= syntax OctetString. Not sure whether there's a clean way to determine the= number of Unicode code points. Ciao, Michael. --------------ms090008060908020301080505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyNDA3MDc0OFowIwYJKoZIhvcNAQkEMRYE FOYp7BL4H+GvaSFu+gwu4Sv9mOnZMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEA6EjfLNSrrqaW1xIErl+IKpDl7AXerZu3jQj4lZPuP6neHv8WWMHnQ1RaRx7hEvzp1kzt dFcq2da/fZdDBu2KgvAD+eqomHomtHwJPXWfyuhnzdhYCCcW2VG+AzMWyh5q0ea8QsoAPRzG cpF0zcVu6AC+PzT+gS/IwKZyLR3lrynILYLks9W8ponF2Am9clbWmaJx/3WES0NXgUf7s43U SWULCIxH2cXrMuZk5kwWbqx6QwmRGQFUR+8o7eV1WB+IkB6PkI1+027gtdzmxLLlFKQXSXkk IDlmfdYakh3iEMkm8o8IQ3AsXabFrvxoM3wRB/J0leJLob4E3CIYYF0WEQAAAAAAAA== --------------ms090008060908020301080505--

1 0

(ITS#7259) Ppolicy count bytes not characters
by Jiri.Netolicky＠cdt.cz 24 Apr '12

24 Apr '12

Full_Name: Jiří Netolický Version: 2.4.30 OS: Linux - Gentoo URL: Submission from: (NULL) (2001:1a48:5:3::3) Slapo-ppolicy manual page says: pwdMinLength: ..this attribute contains the minimum number of characters that will be accepted in a password But it seems that the code not chcount number of characters but number of bytes. I set pwdMinLength to value 8. When I used password with only ascii characters everything works great. But when I use a two-byte UTF-8 character in password it count this one character as two. For example when I use password "babička" which is 7 characters length but the UTF-8 representation is 8 bytes (0x62 0x61 0x62 0x69 0xc4 0x8d 0x6b 0x61). This password is accepted although the policy forces 8 characters min.length. I think the only soulution is correct the manual page the pwdMinLength count bytes not characters. Because userPassword attribute is binary, in my opinion we should not assume that the password encoding is UTF8 to easy count characters.

1 0

(ITS#7258) Possible suffixmassage and syncrepl bug
by jckidder＠aep.com 23 Apr '12

23 Apr '12

Full_Name: Jon C. Kidder Version: 2.4.30 OS: rhel 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (167.239.77.30) Gentlemen, I need some help. I've been working on a problem for a couple of weeks and I can't seem to find a solution. I have encountered at least one bug and possibly two. I am building a new directory for my company using OpenLDAP 2.4.30 and BDB 5.3.15. I am trying to pull in records from a foreign directory and map them into my directory. All of the foreign records are proxied into 3 child nodes of my directory. I am able to do this successfully using back-ldif and overlay-rwm. The problem I am encountering is that I have setup multi-master replication of the entire new directory with a filter to exclude the proxied nodes because each of my directory servers independently proxies those nodes. When the replication starts syncrepl causes an ABEND on every node that attempts replication. I have discovered that the ABEND occurs because my filter does not work and syncrepl is trying to replicate the proxied records. I have also discovered that my filter is not working because rwm-suffixmassage does not appear to be rewriting the entryDN of my proxied records. If my entryDN problem is configuration related I could use some help figuring it out. I am still submitting this as a bug because even if the entryDN problem is not a bug syncrepl should detect the replication/proxy conflict and abort the replication gracefully rather than ABEND the directory server. I love the work the OpenLDAP team is doing. I am a very strong advocate of open source products at my company. I would love to take a deep dive into the code and resolve this issue myself but unfortunately can not. I am an administrator/operator by day and a single parent of 6 year old triplet boys by night. I am not afforded as many opportunities to exercise my development skills as I would like. Any assistance the OpenLDAP team can render would be greatly appreciated. I can try to build a complete test suite that will allow recreation/testing of these 2 issues if needed. Sample ldapsearch result showing inconsistent DN rewrite (DN is rewritten but entryDN is not): /appl/openldap/bin/ldapsearch -x -D "cn=Directory Manager,dc=Global,dc=aep,dc=com" -y $HOME/buildpwd -s sub -b 'dc=Global,dc=aep,dc=com' '(cn=s012235)' '+' # extended LDIF # # LDAPv3 # base <dc=Global,dc=aep,dc=com> with scope subtree # filter: (cn=s012235) # requesting: + # # s012235, Information Technology, AD_Corp, Employees, Users, Global.aep.com dn: cn=s012235,ou=Information Technology,ou=AD_Corp,ou=Employees,ou=Users,dc=G lobal,dc=aep,dc=com entryDN: cn=s012235,ou=Information Technology,ou=LOB Users,dc=corp,dc=aepsc,dc =com subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Log excerpt showing syncrepl abend: 4f9165ba Config: ** successfully added syncrepl rid=401 "ldap://ctldapcop1.aepsc.com:33389" 4f9165ba Config: ** successfully added syncrepl rid=402 "ldap://ctldaprop1.aepsc.com:33389" 4f9165ba syncprov_matchops: skipping original sid 001 4f9165ba slap_graduate_commit_csn: removing 0x1b4a94f0 20120420133346.749007Z#000000#001#000000 4f9165ba syncrepl_entry: rid=001 be_modify olcDatabase={4}bdb,cn=config (0) 4f9165ba slap_queue_csn: queing 0x1b4b3e50 20120420133346.749007Z#000000#001#000000 4f9165ba slap_graduate_commit_csn: removing 0x1b4a8cd0 20120420133346.749007Z#000000#001#000000 4f9165ba conn=1005 fd=23 ACCEPT from IP=10.92.123.82:45250 (IP=10.21.206.102:33389) 4f9165ba conn=1005 op=0 BIND dn="cn=syncuser,ou=automatons,ou=users,dc=global,dc=aep,dc=com" method=128 4f9165ba conn=1005 op=0 RESULT tag=97 err=49 text= 4f9165ba conn=1005 op=1 UNBIND 4f9165ba conn=1005 fd=23 closed 4f9165ba syncrepl_message_to_entry: rid=401 DN: dc=Global,dc=aep,dc=com, UUID: 750d95da-e7bb-483a-853b-9552466e3d0d 4f9165ba syncrepl_entry: rid=401 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 4f9165ba syncrepl_entry: rid=401 inserted UUID 750d95da-e7bb-483a-853b-9552466e3d0d *** glibc detected *** /appl/openldap/libexec/slapd: free(): invalid pointer: 0x000000001b77f8a7 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3c82c7245f] /lib64/libc.so.6(cfree+0x4b)[0x3c82c728bb] /appl/openldap/libexec/slapd[0x5aa324] /appl/openldap/libexec/slapd[0x46f36c] /appl/openldap/libexec/slapd[0x43aca6] /appl/openldap/libexec/slapd[0x4230fe] /appl/openldap/libexec/slapd[0x560550] /appl/openldap/libexec/slapd[0x560632] /appl/openldap/libexec/slapd[0x55ce73] /appl/openldap/libexec/slapd[0x483a7b] /appl/openldap/libexec/slapd[0x483f9a] /appl/openldap/libexec/slapd[0x4840ce] /appl/openldap/libexec/slapd[0x480bd8] /appl/openldap/libexec/slapd[0x48227f] /appl/openldap/libexec/slapd[0x483a7b] /appl/openldap/libexec/slapd[0x483f9a] /appl/openldap/libexec/slapd[0x4840ce] /appl/openldap/libexec/slapd[0x47a44a] /appl/openldap/libexec/slapd[0x480667] /appl/openldap/libexec/slapd[0x580b20] /lib64/libpthread.so.0[0x3c8340673d] /lib64/libc.so.6(clone+0x6d)[0x3c82cd44bd] ======= Memory map: ======== 00400000-007ac000 r-xp 00000000 fd:00 933895 /appl/openldap/libexec/slapd 009ab000-009ca000 rw-p 003ab000 fd:00 933895 /appl/openldap/libexec/slapd 009ca000-00a73000 rw-p 009ca000 00:00 0 1b3e3000-1b8bb000 rw-p 1b3e3000 00:00 0 [heap] 41be1000-41be2000 ---p 41be1000 00:00 0 41be2000-423e2000 rw-p 41be2000 00:00 0 423e2000-423e3000 ---p 423e2000 00:00 0 423e3000-42be3000 rw-p 423e3000 00:00 0 42be3000-42be4000 ---p 42be3000 00:00 0 42be4000-433e4000 rw-p 42be4000 00:00 0 3c82800000-3c8281c000 r-xp 00000000 fd:fa 65572 /lib64/ld-2.5.so 3c82a1c000-3c82a1d000 r--p 0001c000 fd:fa 65572 /lib64/ld-2.5.so 3c82a1d000-3c82a1e000 rw-p 0001d000 fd:fa 65572 /lib64/ld-2.5.so 3c82c00000-3c82d4e000 r-xp 00000000 fd:fa 65579 /lib64/libc-2.5.so 3c82d4e000-3c82f4e000 ---p 0014e000 fd:fa 65579 /lib64/libc-2.5.so 3c82f4e000-3c82f52000 r--p 0014e000 fd:fa 65579 /lib64/libc-2.5.so 3c82f52000-3c82f53000 rw-p 00152000 fd:fa 65579 /lib64/libc-2.5.so 3c82f53000-3c82f58000 rw-p 3c82f53000 00:00 0 3c83000000-3c83002000 r-xp 00000000 fd:fa 65632 /lib64/libdl-2.5.so 3c83002000-3c83202000 ---p 00002000 fd:fa 65632 /lib64/libdl-2.5.so 3c83202000-3c83203000 r--p 00002000 fd:fa 65632 /lib64/libdl-2.5.so 3c83203000-3c83204000 rw-p 00003000 fd:fa 65632 /lib64/libdl-2.5.so 3c83400000-3c83416000 r-xp 00000000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83416000-3c83615000 ---p 00016000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83615000-3c83616000 r--p 00015000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83616000-3c83617000 rw-p 00016000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83617000-3c8361b000 rw-p 3c83617000 00:00 0 3c84c00000-3c84c04000 r-xp 00000000 fd:fa 65883 /lib64/libuuid.so.1.2 3c84c04000-3c84e03000 ---p 00004000 fd:fa 65883 /lib64/libuuid.so.1.2 3c84e03000-3c84e04000 rw-p 00003000 fd:fa 65883 /lib64/libuuid.so.1.2 3c8ea00000-3c8ea11000 r-xp 00000000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ea11000-3c8ec11000 ---p 00011000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ec11000-3c8ec12000 r--p 00011000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ec12000-3c8ec13000 rw-p 00012000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ec130Aborted Relevant configuration ldifs: Database Build: dn: olcDatabase={1}ldap,cn=configolcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="XXXXXXXXXXXXXXXXXXXXX" credentials="XXXXXXXX" keepalive=0:0:0olcDbChaseReferrals: TRUEolcLastMod: FALSEolcAddContentAcl: FALSEolcDatabase: {1}ldapolcSuffix: ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=comolcDbConnectionPoolMax: 16olcDbUseTemporaryConn: FALSEolcDbTFSupport: noolcDbCancel: abandonolcDbProtocolVersion: 3olcReadOnly: FALSEolcSubordinate: TRUEolcDbStartTLS: none starttls=noolcDbNoRefs: FALSEolcDbProxyWhoAmI: FALSEolcMaxDerefDepth: 15olcDbSingleConn: FALSEolcDbNoUndefFilter: FALSEolcDbURI: "ldap://msad-corp.aepsc.com"olcMonitoring: FALSEolcSyncUseSubentry: FALSEolcDbRebindAsUser: TRUEobjectClass: olcDatabaseConfigobjectClass: olcLDAPConfigdn: olcOverlay=rwm,olcDatabase={1}ldap,cn=configolcRwmNormalizeMapped: FALSEobjectClass: olcOverlayConfigobjectClass: olcRwmConfigolcRwmMap: objectclass inetOrgPerson userolcRwmMap: objectclass organizationalUnit *olcRwmMap: attribute cn *olcRwmMap: attribute sn *olcRwmMap: attribute telephoneNumber otherTelephoneolcRwmMap: attribute description *olcRwmMap: attribute title *olcRwmMap: attribute postalCode *olcRwmMap: attribute postalAddress streetAddressolcRwmMap: attribute physicalDeliveryOfficeName *olcRwmMap: attribute st *olcRwmMap: attribute l *olcRwmMap: attribute departmentNumber aepDepartmentIDolcRwmMap: attribute displayName *olcRwmMap: attribute employeeNumber employeeIDolcRwmMap: attribute givenName *olcRwmMap: attribute initials *olcRwmMap: attribute mail mailolcRwmMap: attribute manager aepManagerIDolcRwmMap: attribute mobile *olcRwmMap: attribute o aepFBUDescriptionolcRwmMap: attribute roomNumber aepFloorolcRwmMap: attribute uid sAMAccountNameolcRwmMap: attribute ou aepBBUDescriptionolcRwmMap: attribute * olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" "ou=LOB Users,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com" "ou=Security Groups,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" "ou=Service Accounts,dc=corp,dc=aepsc,dc=com"olcRwmTFSupport: falseolcOverlay: rwmdn: olcDatabase={2}ldap,cn=configolcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="XXXXXXXXXXXXXXXXXXXXX" credentials="XXXXXXXX" keepalive=0:0:0olcDbChaseReferrals: TRUEolcLastMod: FALSEolcAddContentAcl: FALSEolcDatabase: {2}ldapolcSuffix: ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=comolcDbConnectionPoolMax: 16olcDbUseTemporaryConn: FALSEolcDbTFSupport: noolcDbCancel: abandonolcDbProtocolVersion: 3olcReadOnly: FALSEolcSubordinate: TRUEolcDbStartTLS: none starttls=noolcDbNoRefs: FALSEolcDbProxyWhoAmI: FALSEolcMaxDerefDepth: 15olcDbSingleConn: FALSEolcDbNoUndefFilter: FALSEolcDbURI: "ldap://msad-corp.aepsc.com"olcMonitoring: FALSEolcSyncUseSubentry: FALSEolcDbRebindAsUser: TRUEobjectClass: olcDatabaseConfigobjectClass: olcLDAPConfigdn: olcOverlay=rwm,olcDatabase={2}ldap,cn=configolcRwmNormalizeMapped: FALSEobjectClass: olcOverlayConfigobjectClass: olcRwmConfigolcRwmMap: objectclass groupOfUniqueNames groupolcRwmMap: objectclass organizationalUnit *olcRwmMap: attribute cn *olcRwmMap: attribute description *olcRwmMap: attribute uniqueMember memberolcRwmMap: attribute o *olcRwmMap: attribute ou *olcRwmMap: attribute * olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" "ou=LOB Users,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com" "ou=Security Groups,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" "ou=Service Accounts,dc=corp,dc=aepsc,dc=com"olcRwmTFSupport: falseolcOverlay: rwmdn: olcDatabase={3}ldap,cn=configolcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="XXXXXXXXXXXXXXXXXXXXX" credentials="XXXXXXXX" keepalive=0:0:0olcDbChaseReferrals: TRUEolcLastMod: FALSEolcAddContentAcl: FALSEolcDatabase: {3}ldapolcSuffix: ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=comolcDbConnectionPoolMax: 16olcDbUseTemporaryConn: FALSEolcDbTFSupport: noolcDbCancel: abandonolcDbProtocolVersion: 3olcReadOnly: FALSEolcSubordinate: TRUEolcDbStartTLS: none starttls=noolcDbNoRefs: FALSEolcDbProxyWhoAmI: FALSEolcMaxDerefDepth: 15olcDbSingleConn: FALSEolcDbNoUndefFilter: FALSEolcDbURI: "ldap://msad-corp.aepsc.com"olcMonitoring: FALSEolcSyncUseSubentry: FALSEolcDbRebindAsUser: TRUEobjectClass: olcDatabaseConfigobjectClass: olcLDAPConfigdn: olcOverlay=rwm,olcDatabase={3}ldap,cn=configolcRwmNormalizeMapped: FALSEobjectClass: olcOverlayConfigobjectClass: olcRwmConfigolcRwmMap: objectclass inetOrgPerson userolcRwmMap: objectclass organizationalUnit *olcRwmMap: attribute cn *olcRwmMap: attribute sn *olcRwmMap: attribute telephoneNumber otherTelephoneolcRwmMap: attribute description *olcRwmMap: attribute title *olcRwmMap: attribute postalCode *olcRwmMap: attribute postalAddress streetAddressolcRwmMap: attribute physicalDeliveryOfficeName *olcRwmMap: attribute st *olcRwmMap: attribute l *olcRwmMap: attribute departmentNumber aepDepartmentIDolcRwmMap: attribute displayName *olcRwmMap: attribute employeeNumber employeeIDolcRwmMap: attribute givenName *olcRwmMap: attribute initials *olcRwmMap: attribute mail mailolcRwmMap: attribute manager aepManagerIDolcRwmMap: attribute mobile *olcRwmMap: attribute o aepFBUDescriptionolcRwmMap: attribute roomNumber aepFloorolcRwmMap: attribute uid sAMAccountNameolcRwmMap: attribute ou aepBBUDescriptionolcRwmMap: attribute * olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" "ou=LOB Users,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com" "ou=Security Groups,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" "ou=Service Accounts,dc=corp,dc=aepsc,dc=com"olcRwmTFSupport: falseolcOverlay: rwmdn: olcDatabase={4}bdb,cn=configolcDbSearchStack: 16olcDbIDLcacheSize: 0olcDbDNcacheSize: 0olcLastMod: TRUEolcAddContentAcl: FALSEolcDatabase: {4}bdbolcSuffix: dc=Global,dc=aep,dc=comolcDbDirtyRead: FALSEolcDbCacheSize: 1000olcReadOnly: FALSEolcDbCacheFree: 1olcDbDirectory: /appl/openldap/var/openldap-data/GlobalolcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxlPTI+olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhlaXIgLXEgb3B0aW9uKS4golcMaxDerefDepth: 15olcDbMode: 0600olcDbIndex: objectClass eqolcDbIndex: entryUUID eqolcDbIndex: entryCSN eqolcDbIndex: cn pres,eq,approx,subolcDbIndex: uid pres,eq,approx,subolcDbIndex: sn pres,eq,approx,subolcMonitoring: TRUEolcDbNoSync: FALSEolcSyncUseSubentry: FALSEolcRootPW: XXXXXXXXXXXXobjectClass: olcDatabaseConfigobjectClass: olcBdbConfigolcDbShmKey: 0olcDbLinearIndex: FALSEolcRootDN: cn=Directory Manager,dc=Global,dc=aep,dc=comdn: olcOverlay=glue,olcDatabase={4}bdb,cn=configchangetype: addobjectClass: olcOverlayConfigolcOverlay: glue Establish replication: dn: olcOverlay=syncprov,olcDatabase={4}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcSpCheckpoint: 10 1 olcSpReloadHint: TRUE olcOverlay: syncprov dn: olcDatabase={4}bdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=401 provider=ldap://ctldapcop1.aepsc.com:33389 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=global,dc=aep,dc=com" bindmethod=simple credentials="XXXXXXXXXXX" searchbase="dc=global,dc=aep,dc=com" filter="(&(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com)))" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: rid=402 provider=ldap://ctldaprop1.aepsc.com:33389 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=global,dc=aep,dc=com" bindmethod=simple credentials="XXXXXXXXXXX" searchbase="dc=global,dc=aep,dc=com" filter="(&(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com)))" type=refreshAndPersist retry="5 5 300 +" timeout=1 - replace: olcMirrorMode olcMirrorMode: TRUE

1 0

Re: (ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2012 06:06 PM, ondrej.kuznik(a)acision.com wrote: > On 04/13/2012 04:00 PM, ondrej.kuznik(a)acision.com wrote: >> On 03/20/2012 11:11 AM, ondrej.kuznik(a)acision.com wrote: >>> For slapmodify to be usable on a database, that database needs >>> to implement the bi_tool_dn2id_get and bi_tool_entry_modify >>> functions, which is not the case of the back-config. I've put >>> together a minimal (and maybe too naive) implementation of >>> these for back-config and back-ldif at the above link. > >> Ok, nevermind for now, the implementation was too naive and >> would break some other things (the slapadd in test005). > > I prepared an updated version of the patches below, patches > 1-4,8-12 add this support and introduce a new testcase, temporarily > assigned to the currently free position 007 which will ignore > errors, if encountered during slapmodify invocation. > > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… I > forgot to include the IPR Notice for the above patch series: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik A: Because it destroys the flow of the conversation. Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists or on Usenet? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Vfs4ACgkQ9GWxeeH+cXvwDgCeNPRxiAxBZgzX0XDeToxPz71S YTcAoIiwPVXu5zg0TG+o/tdIFlKqd/fO =thvs -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7257) slapdelete hooks
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) To support deletes in tool mode, I tried drafting a new hook for backends to expose, and implemented that for back-ldif. That, and slapmodify support for this operation are included in patches 5-7 in the above patch series. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2012 04:00 PM, ondrej.kuznik(a)acision.com wrote: > On 03/20/2012 11:11 AM, ondrej.kuznik(a)acision.com wrote: >> For slapmodify to be usable on a database, that database needs >> to implement the bi_tool_dn2id_get and bi_tool_entry_modify >> functions, which is not the case of the back-config. I've put >> together a minimal (and maybe too naive) implementation of these >> for back-config and back-ldif at the above link. > > Ok, nevermind for now, the implementation was too naive and would > break some other things (the slapadd in test005). I prepared an updated version of the patches below, patches 1-4,8-12 add this support and introduce a new testcase, temporarily assigned to the currently free position 007 which will ignore errors, if encountered during slapmodify invocation. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VfbEACgkQ9GWxeeH+cXsfNgCfcbPewsqwd5kSW3tHCzqCBfn1 G7gAn3mRB0UoG50F1ezbBLSAzsFDRIhX =J2sk -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7256) back-mdb segfaults trying to free an entry in tool mode
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) I am not entirely sure that I'm doing everything right, but in slapmodify the fake operation has to set op->o_hdr for several functions to use, but has no intention of setting o_tmpmfuncs. This makes slapd segfault when it is used with back-mdb as it only checks whether o_hdr is set. The last patch in the series at the above URL fixes this, but maybe some other change is more appropriate. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#7255) back-mdb hangs during mdb_tool_entry_modify
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) When calling mdb_tool_entry_modify, a new transaction is being set up and this hangs the process on a mutex that the thread already holds. For a possible patch see the last patch in the series at the above URL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#7254) back-bdb cursor is sometimes not available in tool mode
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) bdb_tool_entry_modify unsets the cursor variable, however bdb_tool_entry_get_int expects it to be there whenever it is run. For a possible patch see the last patch in the series at the above URL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 9:17 AM, michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms080904050007060500070608 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Kurt(a)OpenLDAP.org wrote: >> Client's really should, in general, just do their own sorting over the >> result set, especially for sorting entries for presentation purposes. > > People are always asking for paged displaying of address book data sorted= > by > name. If you have large result sets that's a problem at the client's side= > =2E Most of the server side paging is done stateless, which means that if a client relies on it, it's going to have data consistency problems (in the face of possible data or other changes). If you do it stateful on the server side to ensure data consistency, you kill your server. Most clients can easily deal with large data sets, even mobile devices. In many bandwidth constrained environments, roundtrips are even more problematic than the bandwidth issues. So dealing with presentation issues is often best for everyone. But the issue of this thread is sorting... (which often is used with paging). Code point sorting, as you get on the server side (at least with standard ordering rules), ain't what most clients actually want. And even if you have a desirable to the client ordering rule, the handling of multiple valued attributes called for in RFC 2891 is likely not what the client wants. So you end up needing the dup-entry control as well, and that adds more bandwidth and, if paging, more roundtrips. My guidance is to have client deal with presentation issues, which is what most sorting boils down to. > > But my feeling here is also ambivalent. I always tell people to narrow th= > e > search because wading through large result sets by clicking through pages= > is > not very efficient for the user himself anyway. Same problem with users > constantly asking for tree browsing. A horrible inefficient UI tool in la= > rger > deployments... > >> The only case where I see this control being useful is, in conjunction = > with >> the paged results control, for asking for the entry with the lowest/hig= > hest >> single-valued serial number (or like) attributes. > > For suggesting the next free unique number in an input form? Or for just assigning the next free serial number in decreasing/increasing order. (I rather avoid them, but some times you cannot avoid them (due to not owning the requirements). > > Ciao, Michael. > > > --------------ms080904050007060500070608 > Content-Type: application/pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > Content-Description: S/MIME Cryptographic Signature > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC > BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w > HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu > ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx > MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj > MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA > A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd > NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV > hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ > 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ > NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH > AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy > IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl > cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB > BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov > L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq > hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj > /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd > dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH > SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ > AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 > TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT > QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ > R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv > n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy > D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB > gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx > IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 > cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq > hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDE2MTY1OVowIwYJKoZIhvcNAQkEMRYE > FLqReNhqM0dMvax8KwzbLzq2PziaMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG > CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq > hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc > BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n > IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG > CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 > Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh > MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE > ggEAyVNeNLp1NZXO0tamjjP+hri2OEvcaw5ik9BhpeqH8Vu88UsTd33c5Md3tdYNsXF6D9ud > V8+dFYOSU9E7CTHdfdLojAW3HsBoQYuMvJWq74SkYOoShn8DQ1rG4PGIdOW0ZiUvZTzT+sRY > UEY1Yst/iUG+N5LTaM5IMUoH/GMcgab2pWUSLkF+YkNG05XLHkg9tdIj51xCRP9Ic4kfDQos > zD+TsKM/39xyEBtMMGjBnPUxGurKIdvltS95Z1bZ15L4PApHKMWZBIfizbO8KrFUEA8YT8IQ > +grclVEKMgwybt9K2m3dQ1Vn3niIioysIJED9CVoK00ylvSkpC8fsjMtfAAAAAAAAA== > --------------ms080904050007060500070608-- > >

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by michael＠stroeder.com 20 Apr '12

20 Apr '12

This is a cryptographically signed message in MIME format. --------------ms080904050007060500070608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt(a)OpenLDAP.org wrote: > Client's really should, in general, just do their own sorting over the > result set, especially for sorting entries for presentation purposes. People are always asking for paged displaying of address book data sorted= by name. If you have large result sets that's a problem at the client's side= =2E But my feeling here is also ambivalent. I always tell people to narrow th= e search because wading through large result sets by clicking through pages= is not very efficient for the user himself anyway. Same problem with users constantly asking for tree browsing. A horrible inefficient UI tool in la= rger deployments... > The only case where I see this control being useful is, in conjunction = with > the paged results control, for asking for the entry with the lowest/hig= hest > single-valued serial number (or like) attributes. For suggesting the next free unique number in an input form? Ciao, Michael. --------------ms080904050007060500070608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDE2MTY1OVowIwYJKoZIhvcNAQkEMRYE FLqReNhqM0dMvax8KwzbLzq2PziaMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAyVNeNLp1NZXO0tamjjP+hri2OEvcaw5ik9BhpeqH8Vu88UsTd33c5Md3tdYNsXF6D9ud V8+dFYOSU9E7CTHdfdLojAW3HsBoQYuMvJWq74SkYOoShn8DQ1rG4PGIdOW0ZiUvZTzT+sRY UEY1Yst/iUG+N5LTaM5IMUoH/GMcgab2pWUSLkF+YkNG05XLHkg9tdIj51xCRP9Ic4kfDQos zD+TsKM/39xyEBtMMGjBnPUxGurKIdvltS95Z1bZ15L4PApHKMWZBIfizbO8KrFUEA8YT8IQ +grclVEKMgwybt9K2m3dQ1Vn3niIioysIJED9CVoK00ylvSkpC8fsjMtfAAAAAAAAA== --------------ms080904050007060500070608--

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by clem.oudot＠gmail.com 20 Apr '12

20 Apr '12

Le 20 avril 2012 18:00, <Kurt(a)openldap.org> a écrit : > > On Apr 20, 2012, at 8:25 AM, kurt(a)openldap.org wrote: > >>> which use the sss >>> control on standards attributes like cn or sn. >> >> maybe you should file a bug report with them. > > and I should note that I consider most client use of this control, itself, to be a bug. Ok Kurt, I let you explain that to Microsoft and IBM ;) By the way, I understand your arguments, I just wanted to notify the OpenLDAP team of this problem, because that can force customers to use another LDAP directory in order to stay compatible with such (buggy) softwares. Clément.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 8:25 AM, kurt(a)openldap.org wrote: >> which use the sss >> control on standards attributes like cn or sn. > > maybe you should file a bug report with them. and I should note that I consider most client use of this control, itself, to be a bug. Client's really should, in general, just do their own sorting over the result set, especially for sorting entries for presentation purposes. The only case where I see this control being useful is, in conjunction with the paged results control, for asking for the entry with the lowest/highest single-valued serial number (or like) attributes. -- Kurt

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 20 Apr '12

20 Apr '12

We seem to be two guys discussing work we're not volunteering to do anytime soon, but anyway... On Fri, 20 Apr 2012 07:22:32 GMT, masarati(a)aero.polimi.it wrote: > On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote: >> No, I meant the opposite: The macroization is done. It could mostly >> be >> scripted and makes no semantic change unless #ifdef(SlapReply >> debug), >> which is what the macros were for. > > Right. Actually one simpler but uglier macro is enough, without touching non-internal calls: /* * Do ACT with OP->o_internal set. * Example: WITH_INTERNAL_OP( op, rc = op->o_bd->be_add( op, rs )); */ #define WITH_INTERNAL_OP(op, act) do { \ int *const wio_intern_ = &(op)->o_internal; \ int const wio_save_ = (*wio_intern_)++; \ act; \ (*wio_intern_)--; \ assert(*wio_intern_ == wio_save_); /* Keep this while testing */ \ } while (0) Not my preference, but at least it's an option. >> Figuring out which ops to tag as internal does, as you say, require >> review and testing. And one extra arg to the macros. > > How do you suggest to proceed? If I were doing it, I'd play in a separate branch while getting a feel for how it'll end up. Never mind the exact API, it can be rewritten at this stage if it's unsufficient or overkill. Then give master whatever framework is neeed to allow the rest of the job to be done some operation calls at the time, without needing a monster commit to develop and review. Technically, if not just the wrapper macro above: > I believe using different macros, e.g. > slap_bi_op_internal, slap_be_op_internal and SLAP_OP_INTERNAL is > clearer > than having an additional 0/1 parameter. OTOH, adding further > parameters in the future would be probably easier if we extend your > macros. Fair enough. 0/1 could be enum constants, but that's more verbose. And it's just 6 macros for now: My 3 old plus 3 new. /* In proto-slap.h: */ #define slap_bi_op( bi,which,op,rs) ((&(bi)->bi_op_bind)[ which ](op, rs)) #define slap_be_op( be,which,op,rs) slap_bi_op( (be)->bd_info,which,op,rs) #define SLAP_OP( which,op,rs) slap_be_op( (op)->o_bd, which,op,rs) /* Internal operations - as above but with op->o_internal set */ LDAP_SLAPD_F (int) (slap_bi_intop) LDAP_P(( BackendInfo *bi, slap_operation_t which, Operation *op, SlapReply *rs )); #define slap_be_intop(be,which,op,rs) slap_bi_intop((be)->bd_info,which,op,rs) #define SLAP_INTOP( which,op,rs) slap_be_intop(&(op)->o_bd, which,op,rs) /* In backend.c: */ int slap_bi_intop( BackendInfo *bi, slap_operation_t which, Operation *op, SlapReply *rs) { int rc; WITH_INTERNAL_OP( rc = slap_bi_op( bi, which, op, rs )); return rc; } > At this point, we need consensus on addressing ITS#6758 in the first > place. Nah. ITS#6758 needs the macros (at least if I'm to go at it), but the macros don't need ITS#6758 since they don't change what the code does. Hallvard

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 7:56 AM, clem.oudot(a)gmail.com wrote: > Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit : >> Kurt(a)OpenLDAP.org wrote: >>> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: >>> >>>> Kurt(a)OpenLDAP.org wrote: >>>>> Incorrect behavior per the standards. If the control is recognized and >>>> implemented, then it's to be processed regardless of the criticality. There's >>>> not supposed to be any "if it errors, ignore it" processing. >>>> >>>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though. >>> >>> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. >>> >>>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). >>> >>> Both 3 and 4, especially when taken together, overload criticality. >>> >>> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. >>> >>> 4 isn't much better. >>> >>> So the whole specification is a mess. >>> >>> What I recommend is this, >>> >>> If the server implements the control: >>> >>> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. >>> >>> This, I think is consistent with RFC 2891. >>> The client application is assured that the results are sorted in the >>> specified key order if and only if the result code in the >>> sortKeyResponseControl is success. >>> >>> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. >> >> OK. I'm going to add some comments to this effect in sssvlv.c but otherwise >> close this ITS, works as designed. > > I would like just mention that this choice may be relevant from an > RFC/standardization point of view, but will lead to incompatibility of > OpenLDAP with some softwares like Cognos or Outlook, which use the sss > control on standards attributes like cn or sn. maybe you should file a bug report with them. > May it be possible to add an option in the sssvlv overlay to ignore such errors? I prefer not to condone non-standard behaviors by adding workarounds for them.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 7:54 AM, Hallvard Breien Furuseth wrote: >> (...) >> So the whole specification is a mess. >> >> What I recommend is this, >> >> If the server implements the control: >> >> If the control is present, try to sort. If able to do so, return >> sortResult.success. Otherwise return sortResult with sortResult != >> success. >> >> This, I think is consistent with RFC 2891. > > Though the new behavior may be formally compatible with both RFCs, > it certainly breaks the expectations of one of them and must do so. Client developers implementing/using RFC 2891 should only have one key expectation: The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. Clients which assume results are otherwise sorted are simply broken. And, more generally, the client developer should not assume servers adhere to all "shoulds" and "SHOULDs" in a spec. > > How long has the previous behavior been in in OpenLDAP? Is it > feasible to delay the change until RE25? Seems like a typical > kind of change to avoid doing in the middle of a release series. As Howard's comment imply, we implement the behavior I suggest... all he's doing is clarifying in comments the current code behaves consistently with both RFC 2891 and RFC 4510. -- Kurt

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by clem.oudot＠gmail.com 20 Apr '12

20 Apr '12

Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit : > Kurt(a)OpenLDAP.org wrote: >> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> Incorrect behavior per the standards. If the control is recognized and >>> implemented, then it's to be processed regardless of the criticality. There's >>> not supposed to be any "if it errors, ignore it" processing. >>> >>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though. >> >> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. >> >>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). >> >> Both 3 and 4, especially when taken together, overload criticality. >> >> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. >> >> 4 isn't much better. >> >> So the whole specification is a mess. >> >> What I recommend is this, >> >> If the server implements the control: >> >> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. >> >> This, I think is consistent with RFC 2891. >> The client application is assured that the results are sorted in the >> specified key order if and only if the result code in the >> sortKeyResponseControl is success. >> >> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. > > OK. I'm going to add some comments to this effect in sssvlv.c but otherwise > close this ITS, works as designed. I would like just mention that this choice may be relevant from an RFC/standardization point of view, but will lead to incompatibility of OpenLDAP with some softwares like Cognos or Outlook, which use the sss control on standards attributes like cn or sn. May it be possible to add an option in the sssvlv overlay to ignore such errors? Clément.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by h.b.furuseth＠usit.uio.no 20 Apr '12

20 Apr '12

On Fri, 20 Apr 2012 14:05:34 GMT, Kurt(a)OpenLDAP.org wrote: > RFC 2891 was written before RFC 4510... and to some degree, IIRC, was > the reason why the criticality processing requirements were make more > clear in RFC 4510. Overloading criticality (or any protocol element) > is simply a bad thing. IIRC that was done with the understanding that some control RFCs would have to be rewritten - but apparently nobody volunteered to do the rewrites. > (...) > So the whole specification is a mess. > > What I recommend is this, > > If the server implements the control: > > If the control is present, try to sort. If able to do so, return > sortResult.success. Otherwise return sortResult with sortResult != > success. > > This, I think is consistent with RFC 2891. Though the new behavior may be formally compatible with both RFCs, it certainly breaks the expectations of one of them and must do so. How long has the previous behavior been in in OpenLDAP? Is it feasible to delay the change until RE25? Seems like a typical kind of change to avoid doing in the middle of a release series. -- Hallvard

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by hyc＠symas.com 20 Apr '12

20 Apr '12

Kurt(a)OpenLDAP.org wrote: > On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> Incorrect behavior per the standards. If the control is recognized and >> implemented, then it's to be processed regardless of the criticality. There's >> not supposed to be any "if it errors, ignore it" processing. >> >> Thanks for the confirmation. The text of RFC2891 seems contradictory here though. > > RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. > >> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). > > Both 3 and 4, especially when taken together, overload criticality. > > 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. > > 4 isn't much better. > > So the whole specification is a mess. > > What I recommend is this, > > If the server implements the control: > > If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. > > This, I think is consistent with RFC 2891. > The client application is assured that the results are sorted in the > specified key order if and only if the result code in the > sortKeyResponseControl is success. > > clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. OK. I'm going to add some comments to this effect in sssvlv.c but otherwise close this ITS, works as designed. -- -- 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#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: > Kurt(a)OpenLDAP.org wrote: >> On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: >> >>> Full_Name: Clément OUDOT >>> Version: 2.4.30 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (88.173.78.196) >>> >>> >>> I noticed that with OpenLDAP 2.4.30, a search request with a non >>> criticical sss control on an attribute without ordering matching rule >>> returns an error: >>> >>> clement@ader:~/Programmes/openldap$ bin/ldapsearch -H >>> ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b >>> ou=people,ou=XXX -E sss=cn >>> # extended LDIF >>> # >>> # LDAPv3 >>> # with server side sorting control >>> # >>> >>> # search result >>> search: 2 >>> result: 18 Inappropriate matching >>> text: serverSort control: No ordering rule >>> >>> # numResponses: 1 >>> >>> I think the error should only be returned if the control is critical. Else, the >>> search results should be returned, not sorted. >> >> Incorrect behavior per the standards. If the control is recognized and > implemented, then it's to be processed regardless of the criticality. There's > not supposed to be any "if it errors, ignore it" processing. > > Thanks for the confirmation. The text of RFC2891 seems contradictory here though. RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. > Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). Both 3 and 4, especially when taken together, overload criticality. 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. 4 isn't much better. So the whole specification is a mess. What I recommend is this, If the server implements the control: If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. This, I think is consistent with RFC 2891. The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. > > I remember we had this conversation about control criticality before, but don't recall the details. Does the later clarification of Criticality supersede the text of RFC2891? > > -- > -- 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#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 20 Apr '12

20 Apr '12

> OK, thanks for confirmation. I will report a bug for sudo. http://www.sudo.ws/bugs/show_bug.cgi?id=554

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by hyc＠symas.com 20 Apr '12

20 Apr '12

Kurt(a)OpenLDAP.org wrote: > On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: > >> Full_Name: Clément OUDOT >> Version: 2.4.30 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> I noticed that with OpenLDAP 2.4.30, a search request with a non >> criticical sss control on an attribute without ordering matching rule >> returns an error: >> >> clement@ader:~/Programmes/openldap$ bin/ldapsearch -H >> ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b >> ou=people,ou=XXX -E sss=cn >> # extended LDIF >> # >> # LDAPv3 >> # with server side sorting control >> # >> >> # search result >> search: 2 >> result: 18 Inappropriate matching >> text: serverSort control: No ordering rule >> >> # numResponses: 1 >> >> I think the error should only be returned if the control is critical. Else, the >> search results should be returned, not sorted. > > Incorrect behavior per the standards. If the control is recognized and implemented, then it's to be processed regardless of the criticality. There's not supposed to be any "if it errors, ignore it" processing. Thanks for the confirmation. The text of RFC2891 seems contradictory here though. Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). I remember we had this conversation about control criticality before, but don't recall the details. Does the later clarification of Criticality supersede the text of RFC2891? -- -- 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#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: > Full_Name: Clément OUDOT > Version: 2.4.30 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > I noticed that with OpenLDAP 2.4.30, a search request with a non > criticical sss control on an attribute without ordering matching rule > returns an error: > > clement@ader:~/Programmes/openldap$ bin/ldapsearch -H > ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b > ou=people,ou=XXX -E sss=cn > # extended LDIF > # > # LDAPv3 > # with server side sorting control > # > > # search result > search: 2 > result: 18 Inappropriate matching > text: serverSort control: No ordering rule > > # numResponses: 1 > > I think the error should only be returned if the control is critical. Else, the > search results should be returned, not sorted. Incorrect behavior per the standards. If the control is recognized and implemented, then it's to be processed regardless of the criticality. There's not supposed to be any "if it errors, ignore it" processing. -- Kurt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs