- openldap-bugs - openldap.org

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 21 Nov '06

21 Nov '06

Since test033 didn't replicate, I ran librtc against a full production config. The SEGV occurred here (note we're not inside malloc due to librtc redzone features): <rtc> Write to unallocated (wua) on thread 11: Attempting to write 1 byte at address 0xc886b0 which is just past heap block of size 128 bytes at 0xc88630 This block was allocated from: [1] default_malloc_ex() at line 79 in "mem.c" [2] CRYPTO_malloc() at line 304 in "mem.c" [3] RSA_eay_private_decrypt() at line 488 in "rsa_eay.c" [4] RSA_private_decrypt() at line 292 in "rsa_lib.c" [5] ssl3_get_client_key_exchange() at line 1454 in "s3_srvr.c" [6] ssl3_accept() at line 448 in "s3_srvr.c" [7] SSL_accept() at line 816 in "ssl_lib.c" [8] ldap_pvt_tls_accept() at line 863 in "tls.c" Location of error: current thread: t@11 =>[1] BN_bn2bin(a = 0xd93ff3d4, to = 0xc886b0 ""), line 649 in "bn_lib.c" [2] RSA_eay_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 576 in "rsa_eay.c" [3] RSA_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 292 in "rsa_lib.c" [4] ssl3_get_client_key_exchange(s = 0xc74500), line 1454 in "s3_srvr.c" [5] ssl3_accept(s = 0xc74500), line 448 in "s3_srvr.c" [6] SSL_accept(s = 0xc74500), line 816 in "ssl_lib.c" [7] ldap_pvt_tls_accept(sb = 0xc74068, ctx_arg = 0xb53bd8), line 863 in "tls.c" [8] connection_read(s = 46), line 1337 in "connection.c" [9] slapd_daemon_task(ptr = (nil)), line 2352 in "daemon.c" This system is running OpenSSL 0.9.7l, although I've seen the #4723 segfault (not under debugger, alas) on 0.9.7d systems as well. Is there any easy way to turn on traffic encryption in 'make test', possibly with some on-the-fly self-gen certs?

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by Frank.Swasey＠uvm.edu 20 Nov '06

20 Nov '06

This is a cryptographically signed message in MIME format. --------------ms020103070007040700000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm slow reading my email (well 18 days isn't so bad really... ahem...) On 11/2/06 2:42 PM, quanah(a)stanford.edu wrote: > As for #2, I grant such a release for the work I've done on the script. > > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Yes, I do grant this release. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------ms020103070007040700000908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0 /joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN 0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy +z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7 ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTEyMDE5NTUxN1owIwYJKoZIhvcNAQkEMRYEFEe5 R0tOqDV5mZSEX9tMzc1x2JoeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQB5jfu/W/bTIPufVHhrEsZS19DtAZXNQisiNsDTRGtdQGyyS9w2 NE0w5B0Lhbhg+dgwBGvd03/OqxwguatStF0fpgW2sFK3pbvClmRA7mXte5d51GNP49COPd4C R1dLsOtzmhHb2YJ8Cg46vZWE/UdgGYYoV4zStPNJHs3Z07pQ5pCBMhd4l/BZht+BPgNiirLv UskWVwSwUfGxfgEka9yG4KLCQdhL44oUXRcawWfrOPcmN80jrXHp6FnsNSJ43ifztqK4QKyY idUeA+NEmv3Ss5AO6PkvC51rsr2qmLkMeczl/ZuvcxGaDDloBibCdWJu5R81pRoTO0UdPfiw uwbIAAAAAAAA --------------ms020103070007040700000908--

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org 20 Nov '06

20 Nov '06

At 12:36 AM 11/20/2006, michael(a)stroeder.com wrote: >Kurt D. Zeilenga wrote: >> At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >>> >>>I'd like to see support for RFC 3045 in slapd. >> >> The only reasonably decent use of such attributes is for >> administrators to determine whether they need to upgrade >> some software or not > >Yes, that's what I'm after. This purpose is, I think, somewhat beyond the intended purpose of the vendorName/Version attributes. These attributes appear to be intended to be used by general LDAP clients, not just administrative clients, for "limited feature discovery". The vendorName/Version you might want reported for "limited feature discovery" might be quite different than what you want reported for "need to upgrade" purposes. And for "need to upgrade" purposes, one needs to know not only the version of the protocol engine (slapd(8)), but version of backend codes, overlay codes, underlying libraries, etc.. >> We provide cn=monitor for this purpose. > >This is proprietary. Think of vendor-independent management/monitoring >software which just gives an terse overview. Generally speaking, DSA administrative interfaces are not standardized. (Which is, to some degree, why I think use of vendorName/Version for administrative purposes is beyond the intentions of these attributes.) >> While it certainly is possible for a client to abuse >> cn=monitor version information, the very fact that the >> version information is in cn=monitor, which generally >> requires special authorization to read, instead of >> the root dse, which generally is readable by most >> every client, is effective in discouraging this abuse. > >The server admin can easily define access control for vendor information >in root DSE. The sample slapd.conf could endorse this. Or another value >for configuration directive 'allow'. Yes, but... Kurt

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com 20 Nov '06

20 Nov '06

Kurt D. Zeilenga wrote: > At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >> >>I'd like to see support for RFC 3045 in slapd. > > The only reasonably decent use of such attributes is for > administrators to determine whether they need to upgrade > some software or not Yes, that's what I'm after. > We provide cn=monitor for this purpose. This is proprietary. Think of vendor-independent management/monitoring software which just gives an terse overview. > While it certainly is possible for a client to abuse > cn=monitor version information, the very fact that the > version information is in cn=monitor, which generally > requires special authorization to read, instead of > the root dse, which generally is readable by most > every client, is effective in discouraging this abuse. The server admin can easily define access control for vendor information in root DSE. The sample slapd.conf could endorse this. Or another value for configuration directive 'allow'. Ciao, Michael.

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org 20 Nov '06

20 Nov '06

At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >Full_Name: Michael Ströder >Version: not relevant >OS: not relevant >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (83.124.27.203) > > >HI! > >I'd like to see support for RFC 3045 in slapd. The only reasonably decent use of such attributes is for administrators to determine whether they need to upgrade some software or not (though use of a protocol attribute for this purpose is somewhat problematic). We provide cn=monitor for this purpose. The primary use (or I should say misuse) of such strings is for server behavior discovery (whether the behavior is due to a feature or a bug). As this use leads to interoperability problems (as illustrated by the HTTP "mozilla" compatibility problems), we must allow spoofing and should discourage this use. We support the former via the rootdse configuration option. We support the latter by not providing any values by default. While it certainly is possible for a client to abuse cn=monitor version information, the very fact that the version information is in cn=monitor, which generally requires special authorization to read, instead of the root dse, which generally is readable by most every client, is effective in discouraging this abuse. I think it reasonable to assume any administrative tool for determining whether an OpenLDAP server is up to date would have appropriate authorization to read the cn=monitor values. I note that such tools should not assume a server needs not be upgraded simply because the version is high enough. There easily could be dependent software whose version is not high enough. It would be good for cn=monitor to not only expose the OpenLDAP version information, but to expose version information for dependent software. Of course, as there is an endless number of dependent software, this upgrade detection approach problematic. Seems it would be better to use tools that ran directly on the box to determine whether a server's software needed to be upgraded. But I digresss. In the past we have rejected submissions to extend slapd(8) to generate these values, hence I think this feature request should be closed. However, such closure certainly doesn't preclude someone from implementing **additional** vendorName/Version functionality and submitting it for consideration. There is one aspect of our current vendorName/Version support that is lacking is in dealing with multiple broken clients requiring different vendorName/Version strings. An overlay which spoofed these strings on a configurable basis, whether by authorization identity and/or IP address and/or other authorization factor, would be an interesting functionality addition. Kurt

1 0

(ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com 19 Nov '06

19 Nov '06

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.27.203) HI! I'd like to see support for RFC 3045 in slapd. Yes, I know I can set this using configuration directive rootDSE in slapd.conf. But that doesn't really help, especially regarding 'vendorVersion'. Ciao, Michael.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 17 Nov '06

17 Nov '06

Still no good with 2.3.30. I ran 2.3.30 test033 under librtc (valgrind-esque) and it came up clean, so this has to be intermittent or more than a simple config can instigate. [1] t_delete(0xc2c398, 0x50, 0x992e508, 0xfec3c000, 0x0, 0x0), at 0xfebc783c [2] _malloc_unlocked(0x25, 0x0, 0xcb4b0, 0xfec3c000, 0x0, 0x99d3829), at 0xfebc6ecc [3] malloc(0x25, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xd573ef7d), at 0xfebc6d00 =>[4] ber_memalloc_x(s = 37U, ctx = (nil)), line 226 in "memory.c" [5] ch_malloc(size = 37U), line 54 in "ch_malloc.c" [6] hdb_fix_dn(e = 0x99d3630, checkit = 0), line 445 in "dn2id.c" [7] hdb_cache_find_id(op = 0xd57ff4f4, tid = (nil), id = 7586U, eip = 0xd573f2e8, islocked = 0, locker = 150U, lock = 0xd573f26c), line 765 in "cache.c" [8] hdb_search(op = 0xd57ff4f4, rs = 0xd57ff4b8), line 696 in "search.c" [9] syncprov_findcsn(op = 0x3edff0, mode = FIND_PRESENT), line 685 in "syncprov.c" [10] syncprov_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 2056 in "syncprov.c" [11] overlay_op_walk(op = 0x3edff0, rs = 0xd57ffd50, which = op_search, oi = 0x31bfb8, on = 0x31c0b0), line 491 in "backover.c" [12] over_op_func(op = 0x3edff0, rs = 0xd57ffd50, which = op_search), line 551 in "backover.c" [13] over_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 573 in "backover.c" [14] fe_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 355 in "search.c" [15] do_search(op = 0x3edff0, rs = 0xd57ffd50), line 217 in "search.c" [16] connection_operation(ctx = 0xd57ffe14, arg_v = 0x3edff0), line 1122 in "connection.c" [17] ldap_int_thread_pool_wrapper(xpool = 0x2c5df0), line 478 in "tpool.c"

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by quanah＠stanford.edu 17 Nov '06

17 Nov '06

--On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote: > Why was tick ticket closed? The problem still exists. Did you read the notes in the ITS system? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

RE: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by Damon.Groenveld＠ca.com 17 Nov '06

17 Nov '06

Given that the code (in aclparse.c) calls inet_addr() with the peername.ip parameter, I can't see how it could will work with IPv6. The only possible workaround is using a regex instead of ip type which by passes the inet_addr() call. I raised it as a bug since the latest version (as far as I can tell) is meant to support IPv6 and there is no way that peername.ip does and there isn't an alternative. I asked the question regarding other ways to restrict access since I noted that the documentation mentions TCP Wrappers and has a see also of host_options(5) -- which does not exist, so I was hoping that some advice might come while someone looked at the problem (if or when it was deemed important enough). Damon Groenveld CA Architect, Development tel: +61 3 9727 8920 fax: +61 3 9727 3491 mobile: +61 419 922 326 damon.groenveld(a)ca.com -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Friday, 17 November 2006 4:59 PM To: Groenveld, Damon Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername damon.groenveld(a)ca.com wrote: > Full_Name: Damon Groenveld > Version: LATEST > OS: Solaris, WinXP, Linux, AIX, HP-UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.224.6.218) > > > There does not seem to be the ability to specify an IPv6 address in the peername > part of the ACL. > > Is there any other way to restrict access to a host IP address when using only > IPv6 addresses? Software usage questions should be directed to the OpenLDAP-software mailing list. There is no indication of a bug here, most likely this report should be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com 17 Nov '06

17 Nov '06

damon.groenveld(a)ca.com wrote: > Full_Name: Damon Groenveld > Version: LATEST > OS: Solaris, WinXP, Linux, AIX, HP-UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.224.6.218) > > > There does not seem to be the ability to specify an IPv6 address in the peername > part of the ACL. > > Is there any other way to restrict access to a host IP address when using only > IPv6 addresses? Software usage questions should be directed to the OpenLDAP-software mailing list. There is no indication of a bug here, most likely this report should be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4756) IPv6 Addresses are not supported in ACL peername
by damon.groenveld＠ca.com 17 Nov '06

17 Nov '06

Full_Name: Damon Groenveld Version: LATEST OS: Solaris, WinXP, Linux, AIX, HP-UX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.224.6.218) There does not seem to be the ability to specify an IPv6 address in the peername part of the ACL. Is there any other way to restrict access to a host IP address when using only IPv6 addresses?

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 17 Nov '06

17 Nov '06

On Thu, 16 Nov 2006, Howard Chu wrote: > Since the rid is supposed to be unique, would you settle for that? > Particularly since there may be multiple sessions to the same host... Yes, that will do nicely. In the meantime I was getting it to print si->si_bindconf.sb_uri.bv_val, as I sort of need it right now... -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by hyc＠symas.com 17 Nov '06

17 Nov '06

daveh(a)ci.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.3.27 > OS: FreeBSD 4.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.65.182.30) > > > We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). > Should a syncrepl fail, it would be good to know just which peer was causing the > trouble. Could this name (or IP address, or syncrepl host etc) be passed to the > Debug() call? Since the rid is supposed to be unique, would you settle for that? Particularly since there may be multiple sessions to the same host... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 17 Nov '06

17 Nov '06

Full_Name: Dave Horsfall Version: 2.3.27 OS: FreeBSD 4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). Should a syncrepl fail, it would be good to know just which peer was causing the trouble. Could this name (or IP address, or syncrepl host etc) be passed to the Debug() call?

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by hyc＠symas.com 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.4 > OS: FC6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? No, that is impossible. A syncrepl consumer is a client. A client must have the plaintext in order to authenticate. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ando＠sys-net.it 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? > Please don't use the ITS to ask software usage (or development trends) questions. The syncrepl consumer acts as a client with respect to the producer DSA; as a consequence, to be able to perform simple bind, it needs to provide the credentials in cleartext. Either you use a bindmethod different from simple (e.g. SASL) which does not require cleartext credentials (e.g. GSSAPI) or you'll ever need to provide cleartext credentials. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ghenry＠suretecsystems.com 16 Nov '06

16 Nov '06

Full_Name: Gavin Henry Version: 2.4 OS: FC6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in a consumer to be encrypted, and not plain text, like the rootpw can be? Many thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

ITS#3812 database config documentation
by hyc＠symas.com 16 Nov '06

16 Nov '06

I've committed a preliminary slapd-config.5 manpage to HEAD. In anticipation of deleting slurpd from RE24, I have commented out all of the slurpd-related keywords. Most of the text is the same as in slapd.conf(5) but I've changed the organization to better reflect the actual implementation. There may be options that I've missed. Please review and send patches / corrections / comments. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4753) Minor section error in slapo-retcode manpage
by ando＠sys-net.it 15 Nov '06

15 Nov '06

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.30 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.56.0.199) > > > There is a minor typo in slapo-retcode manpage nroff header. > The first line reads: > > .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" > > A blank is missing between SLAPO-RETCODE and the section 5. > Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 15 Nov '06

15 Nov '06

Why was tick ticket closed? The problem still exists. Geert

1 0

(ITS#4753) Minor section error in slapo-retcode manpage
by gael.roualland＠oleane.net 15 Nov '06

15 Nov '06

Full_Name: Gaël Roualland Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) There is a minor typo in slapo-retcode manpage nroff header. The first line reads: .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" A blank is missing between SLAPO-RETCODE and the section 5.

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Russ Allbery 15 Nov '06

15 Nov '06

Quanah Gibson-Mount <quanah(a)stanford.edu> writes: > Russ Allbery <rra(a)debian.org> wrote: >> So, what does it do, then? How doesn't it work? What would work >> instead given the above constraint? > I'll note I opened ITS#4750 upstream on this issue. Howard has said > that if a good security argument can be made, it could be committed into > the current (2.3+ releases). The security argument is made in the Debian bug: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387467> specifically: | > I'm curious about this, are you sure a libldap would read an "ldaprc" | > file when run from a setuid program? | | Yep: | | # ls -l /usr/bin/passwd | -rwsr-xr-x 1 root root 32296 2006-08-25 19:49 /usr/bin/passwd | # mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.away | | $ cd /tmp | $ passwd testuser | passwd: unknown user testuser | $ echo 'TLS_CACERT /etc/ssl/certs/ldapca.pem' > ldaprc | $ passwd testuser | passwd: You may not view or modify password information for testuser. | | > Or that it'd read the | > current-directory ldaprc in that situation? Can you provide an strace | > showing this happening? | | The interesting fragments: | | execve("/usr/bin/passwd", ["passwd", "testuser"], [/* 16 vars */]) = 0 | [...] | access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) | [...] | getuid32() = 1000 | [...] | geteuid32() = 0 | [...] | open("/etc/libnss-ldap.conf", O_RDONLY) = 3 | [...] | open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) | open("ldaprc", O_RDONLY|O_LARGEFILE) = 3 | | There is no path component in the last open(), so ldaprc is always read | from the current directory. | | > Also, the user would have to have access to more than the ldaprc file, | > no? Since the user couldn't control what server is being connected to | > without more control on the system, or control over the DNS, etc. | | True, but DNS poisoning is trivial (especially in a large local network | with lots of not-so-trusted machines). If I'd trust the network I'd have | no need for TLS at all... Clearly the user should have an /etc/ldap/ldap.conf under any normal circumstance, and a configuration that does not is most likely broken. However, my argument is that while there may be cases where a user creating a security vulnerability through a broken configuration is simply the user's problem, I believe this is a case where the action taken has no intuitive connection to security. This was initially noticed because a user was putting all their LDAP options in /etc/libnss-ldap.conf rather than in /etc/ldap/ldap.conf, which may be broken but which is not something that is obviously broken from a *security* standpoint. Having a library attempt to open files in the current directory and read them for configuration is highly non-intuitive and unexpected. Having it read configuration out of the user's home directory is less so, but in the case of setuid programs is still rather disturbing, particularly since the setuid program has no direct control over this behavior. So, I see two potential problems here: * A user can override the LDAP configuration of a setuid binary and cause it to, for instance, trust LDAP servers that it wouldn't otherwise trust, which is a potential attack (albeit a difficult one to exploit). If the setuid binary knows that it's using LDAP, it can avoid this via an environment variable, but frequently given such things as NSS plugins and PAM modules the binary isn't going to know that LDAP is involved. The primary problem here is that said setuid binary will read the configuration file based on HOME from the enviroment (it appears to me from the code) or the current directory (the above example), which violates one of the standard secure programming practices for setuid binaries (never trust the process environment including working directory that you're handed by the user). * The library may fall back to reading a file out of the current directory. I don't know if this behavior persists in 2.3; the above example is from 2.1. If it does persist, it opens other potential problems that don't involve setuid but instead involve creating files in the current working directory of a process one wishes to attack. Again, due to the plugin nature of current operating systems, the process being attacked may not even be aware that it's using LDAP. I think this exploit is unlikely to occur in practice since it requires some attacker control over the home directory of the process being attacked, but it's theoretically present. Steve's patch addresses the first issue but doesn't do much about the second, so it's an improvement but I'm not sure it's a complete solution. Unfortunately, this support is also important for the current functionality of the command-line tools and doubtless other programs that use the LDAP libraries. What we ideally need is some way for a user of the LDAP libraries to say, through the API, that user configuration files should not be loaded but that isn't a process-wide flag that interferes with the expected behavior of other uses of LDAP elsewhere in the same process. And as mentioned, I don't see an obvious way to do that without changing the API, which is, of course, a pain. In the meantime, the patch isn't exactly something I'd want to take upstream either, but it at least addresses the most obvious problem, and more problematically I don't see a better way of addressing it other than saying "well, anyone without a system-wide ldap.conf loses." And I wouldn't be comfortable trying to defend that position. I suppose another possible workaround specific to the NSS module (and probably the PAM module as well) would be to proactively check whether there's a system-wide ldap.conf file and fail immediately if there isn't. That leaves the problem open for other setuid uses of the LDAP libraries, but I don't expect there are a lot of those and what ones there may be are more likely to be able to use the LDAPNOINIT flag. -- Russ Allbery (rra(a)debian.org) <http://www.eyrie.org/~eagle/>

2 6

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by hyc＠symas.com 15 Nov '06

15 Nov '06

quanah(a)stanford.edu wrote: > --On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > > >> I note that nss/pam-ldap setting NOINIT (or otherwise mucking >> with libldap options) might break LDAP-enabled programs. But >> that's another matter. >> >> Anyways, I think the only good fix (for this and many other >> larger problems) is a library redesign/rewrite. > > Okay. > > I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap > source, maybe it was removed at some point? I'm looking at the latest code > from PADL. > > Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the > environment? Which has other problems. For the specific case of nss/pam_ldap the obvious solution is to require that they never use default values anywhere. Generally that is already what happens anyway. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4752) back-config Adds are not atomic
by hyc＠OpenLDAP.org 15 Nov '06

15 Nov '06

Full_Name: Howard Chu Version: HEAD/23/24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When LDAPAdding various types of entries under cn=config, failures in some later portion of the entry will cause the operation to fail but anything already set remains set. The current approach of using check_vals to validate before doing the main processing is inadequate. It may be possible to extend the current pre-check approach, otherwise we'll need to do something like define destructors for everything.

1 0

(ITS#4751) back-perl crashing with anonymous search request
by rhafer＠suse.de 14 Nov '06

14 Nov '06

Full_Name: Ralf Haferkamp Version: HEAD, RE23 OS: SUSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.155.116) I created a simple back-perl setup with the SampleLDAP.pm Module (slightly enhanced with a bind() method that just returns SUCCESS) from CVS Head and slapd crashed on me immediately on receiving the first anonymous search request. It survived however when I issued bind requests followed by search request. While digging through the code I found that back_perl_bind calls "PERL_SET_CONTEXT( PERL_INTERPRETER );" since a few revisions. All other back_perl_* functions (search, delete, modify, ...) do not call PERL_SET_CONTEXT, adding that seems to fix the crash. The perlembed man-pages state related to PERL_SET_CONTEXT: "PERL_SET_CONTEXT(interp) should also be called whenever "interp" is used by a thread that did not create it (using either perl_alloc(), ..." I'll commit a fix that adds PERL_SET_CONTEXT calls to the other functions as well (wrapped behind #ifdefs just like in back_perl_bind()).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs