openldap-bugs September 2013

openldap-bugs@openldap.org

30 participants
114 discussions

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by ck＠cksoft.de 10 Sep '13

10 Sep '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-1091139785-1378839346=:6609 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <alpine.BSF.2.00.1309102056121.6609(a)pohjola.cksoft.de> Hi, On Tue, 10 Sep 2013, Michael Ströder wrote: > ck(a)cksoft.de wrote: >> we have a java application using JNDI that uses the password modify extended >> operation to change user passwords. >> [..] >> When running slapd with heavy logging we save the only difference to ldappasswd >> which works fine against our masters is that JNDI sets the ManageDsaIT by >> default. > > Of course slapd should never crash. yes of course not. This opens an attack vector for shooting down the slapd to at least anyone who has bind access which is concerning me. Apart from that the customers problem is solved. We just stopped sending the control. A bit like Dr. Dr. it hurts when I Do this. Then why don't you stop doing it. > But strictly speaking the semantics of using ManageDsaIT control along with > password modify ext.op. is not specified - at least not in RFC 3062. yes. jndi sets the control by default. >From looking at the assert slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. the comment in chain.c seems to hint at an overly simple assumption. But in understand too little of slapd internals and code flow: 188 static int 189 chaining_control_remove( 190 Operation *op, 191 LDAPControl ***oldctrlsp ) 192 { 193 LDAPControl **oldctrls = *oldctrlsp; 194 195 /* we assume that the first control is the chaining control 196 * added by the chain overlay, so it's the only one we explicitly 197 * free */ 198 if ( op->o_ctrls != oldctrls ) { 199 assert( op->o_ctrls != NULL ); 200 assert( op->o_ctrls[ 0 ] != NULL ); 201 202 free( op->o_ctrls ); 203 204 op->o_chaining = 0; 205 op->o_ctrls = oldctrls; 206 } 207 208 *oldctrlsp = NULL; 209 210 return 0; 211 } Could it be as simple as walking the linked list and just removing the chaining control. Of course another strategy might be to filter anything but the chaining control up front. Greetings Christian > > Ciao, Michael. > > -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1091139785-1378839346=:6609--

1 0

(ITS#7690) OpenLDAP 2.4.36 crashing with MDB
by marco.pizzoli＠gmail.com 10 Sep '13

10 Sep '13

Full_Name: Marco Pizzoli Version: 2.4.36 OS: RHEL 5.4 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) NOTICE: This is not a complete bug report. I'm aware I'm not providing useful information on the exact problem and how to fix it. I'm filing this ITS just to keep track of a crash happened to me with the latest release of OpenLDAP with MDB. WHAT HAS HAPPENED A colleague of mine tried to create a clone of an entry by using a graphic client. Something bad happened during that and as a result he obtained an entry nested 509 times: uid=pippo,uid=pippo,uid=pippo,etc...etc...ou=root When trying to delete the root of those entries, with phpldapadmin, I managed to crash OL without nothing executed. It was an MDB database. I zeroed that db, made it repopulate (it is part of a multi-master topology) by using the HDB database engine and re-tried to delete that (root)entry. This time the operation, even not completing (it dropped only half the of the subtree), it suffered no crash. All other slapds in the multi-master topology crashed. I restated the command on the first and this time it completed well. In the end, I re-used the MDB database after having those entries syncronized by other slapd of the multi-master topology. As said in advance, I simply can't provide any conf or core or anything else.

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by michael＠stroeder.com 10 Sep '13

10 Sep '13

This is a cryptographically signed message in MIME format. --------------ms020200010309050905060801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ck(a)cksoft.de wrote: > we have a java application using JNDI that uses the password modify ext= ended > operation to change user passwords. > [..] > When running slapd with heavy logging we save the only difference to ld= appasswd > which works fine against our masters is that JNDI sets the ManageDsaIT = by > default. Of course slapd should never crash. But strictly speaking the semantics of using ManageDsaIT control along wi= th password modify ext.op. is not specified - at least not in RFC 3062. Ciao, Michael. --------------ms020200010309050905060801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTEwMTgyMzM1WjAj BgkqhkiG9w0BCQQxFgQUEspAhGoCvSxwItIQvDO9RKj4c1kwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEASG/b4BKftKYcHYL3Q2ELEB+o3JQzuFoN kJf0ZxDQGuyOoR55w0WpGITlb+WOblLtZm34rdrB8ZeHbX3AmC4VH4yiuV8wnjByychDpbG0 8w+5Kqgm0Zrl/NYFpSbyYJJu3wvv1Jcj/pgRQ0BTprM95rMbEnC2XnNfp0JQeSZ0BmvbL6Fc R8yPkRqfxrsvHoCaGAlHlRihqSalR0m3JPjMM9H0TcfxJEtz2/rdtjN8zi3RRV94qmwd4qCk JW8FRFQEzdcd8Kjkd3HxRPfTTWNIbnROi9/K7wEb/lGgL8hBkgsz6pRGviD6xpIXZnYZ9+Vw o5+e3J5DNhfWgDgPtKCuRAAAAAAAAA== --------------ms020200010309050905060801--

1 0

Re: (ITS#7689) Configuration directive 'logfile' has no use
by quanah＠zimbra.com 10 Sep '13

10 Sep '13

--On Tuesday, September 10, 2013 4:02 PM +0000 eurban(a)harris.com wrote: > Full_Name: Eric Urban > Version: 2.4.36 > OS: RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (158.147.58.198) > > > Hi, I have been working on packaging 2.4.36 for RHEL 6.4. No issues > there. One requirement is to have logging enabled by default. OpenLDAP > supports syslog, but its use is discouraged within my business area. I > noticed the 'logfile' configuration directive. I still use the > 'slapd.conf' configuration file format, if that matters. I added the > following line to my 'slapd.conf' "logfile" is not a replacement for syslog logging, and is an entirely separate function. Please read the slapd.conf(5) man page. Closing this ITS as invalid. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7689) Configuration directive 'logfile' has no use
by eurban＠harris.com 10 Sep '13

10 Sep '13

Full_Name: Eric Urban Version: 2.4.36 OS: RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.147.58.198) Hi, I have been working on packaging 2.4.36 for RHEL 6.4. No issues there. One requirement is to have logging enabled by default. OpenLDAP supports syslog, but its use is discouraged within my business area. I noticed the 'logfile' configuration directive. I still use the 'slapd.conf' configuration file format, if that matters. I added the following line to my 'slapd.conf' logfile /var/log/openldap/openldap.log loglevel none sync stats Then I did mkdir /var/log/openldap chown ldap:ldap /var/log/openldap I restart OpenLDAP and the log file is created but never written to. If I start openldap with 'slapd -d -1' the log file is written to. I checked in include/ldap_log.h and see that the macros for LogN check against 'ldap_debug' before calling lutil_debug. The pseudo-variable 'ldap_debug' is a preprocessor #define at the bottom of the same file. It is just an integer bitmask for logging. I took a look at servers/slapd/bconfig.c and see that 'config_generic' does an fopen() and then passes the result to lutil_debug_file. So far, so good. In config_loglevel the 'loglevel' directive from my slapd.conf is parsed and assigned to 'ldap_syslog' but never 'ldap_debug'. So slapd in server mode will create this file but never write to it. If you set 'logfile' in slapd.conf and start with the -d flag it will, but this is pretty pointless is as you already have the logging messages in your terminal in that case. Is this intentional? I'm not seeing the utility of the 'logfile' configuration directive. In normal operations it's only purpose will be to create an empty file and to confuse system administrators.

1 0

(ITS#7688) MDB_WRITEMAP + non-writemap process broken
by h.b.furuseth＠usit.uio.no 10 Sep '13

10 Sep '13

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.8 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard mdb_env_open(,,MDB_WRITEMAP,) does not grow the data file to the mapsize if another process has it open without MDB_WRITEMAP. The new MDB_env gets Bus Error in mdb_page_alloc() if it tries to grow mt_next_pgno. Broken by 2e7130cab0129e3b72a25d39c5d4e5a5c55cb353 "Allow mdb_env_set_mapsize() on an open environment". It made ftruncate() conditional on 'newsize'. To avoid mapsize wars between environments? Could do: if (flags & MDB_WRITEMAP) { prot |= PROT_WRITE; if (!newsize) { off_t pos = lseek(env->me_fd, 0, SEEK_END); if (pos == (off_t)-1) return ErrCode(); if ((size_t)pos < env->me_mapsize) newsize = 1; } if (newsize && ftruncate(env->me_fd, env->me_mapsize) < 0) return ErrCode(); } But that still has a race between processes mapping the environment at the same time, one process could shrink the map just after another grew it. And I'm unsure how env->me_mapsize would end up in this case. Another way: Move ftruncate() to mdb_page_alloc(), which has no race. Grow to <new mt_next_pgno + 25%>. To avoid seeks, maintain me_txns->mti_next_pgno in mdb_page_alloc{MDB_WRITEMAP} and txn_reset(writer).

1 0

(ITS#7687) slapd with chaining dies on ManageDsaIT control
by ck＠cksoft.de 10 Sep '13

10 Sep '13

Full_Name: Christian Kratzer Version: 2.4.36 OS: CentOS / RedHat Enterprise URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2003:41:c010:8001:9028:d44e:e3ea:c880) Hi, we have a java application using JNDI that uses the password modify extended operation to change user passwords. This runs fine against our masters but causes an assert when run against our slaves that use chaining to pass the modify request to the masters. slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. Backtrace is as follows: Core was generated by `/usr/local/sbin/slapd -h ldap://:389/ ldaps://:636/ -d 1 -F /usr/local/etc/open'. Program terminated with signal 6, Aborted. #0 0x00007fdf5125c8a5 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install openldap-release-2.4.36-1.el6.x86_64 (gdb) bt #0 0x00007fdf5125c8a5 in raise () from /lib64/libc.so.6 #1 0x00007fdf5125e085 in abort () from /lib64/libc.so.6 #2 0x00007fdf51255a1e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007fdf51255ae0 in __assert_fail () from /lib64/libc.so.6 #4 0x00007fdf4e7fd3ca in chaining_control_remove (op=0x7fdef81add00, oldctrlsp=0x7fdf07ffe078) at chain.c:199 #5 0x00007fdf4e7feedd in ldap_chain_op (op=0x7fdef81add00, rs=0x7fdf07ffe950, op_f=0x7fdf4e7fc680 <ldap_back_extended>, ref=0x7fdef81ae0c0, depth=0) at chain.c:655 #6 0x00007fdf4e7ffd37 in ldap_chain_response (op=0x7fdef81add00, rs=0x7fdf07ffe950) at chain.c:1092 #7 0x00000000004954d8 in ?? () #8 0x000000000043d2ee in ?? () #9 0x000000000043de49 in ?? () #10 0x000000000043e5ae in slap_send_ldap_extended () #11 0x000000000045defc in fe_extended () #12 0x00000000004957e7 in overlay_op_walk () #13 0x00000000004961c7 in ?? () #14 0x000000000045e315 in do_extended () #15 0x000000000042df79 in ?? () #16 0x000000000042e755 in ?? () #17 0x00007fdf52a6d498 in ldap_int_thread_pool_wrapper (xpool=0x13f1450) at tpool.c:688 #18 0x00007fdf515c4851 in start_thread () from /lib64/libpthread.so.0 #19 0x00007fdf5131290d in clone () from /lib64/libc.so.6 (gdb) When running slapd with heavy logging we save the only difference to ldappasswd which works fine against our masters is that JNDI sets the ManageDsaIT by default. We were subsequently able to work around the issue by changing the default JNDI behaviour so as not to set the ManageDSA IT control with: env.put(Context.REFERRAL, "throw"); As detailed in following related post and jndi documentation: http://www.openldap.org/lists/ietf-ldapext/200409/msg00035.html http://docs.oracle.com/javase/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#refer… It would of course be helpfull if slapd would handle the situation slightly more gracefully. Even though the control is utterly useless in our case with chaining it is the default on jndi so handling this case would be helpfull to all java users out there. I am not quire sure where this goes wrong exactly. If anybody can write up a patch I would be more than gratefull to test as we have a reproducible test setup on hand in our lab that we can run any time. I can also retest with fuller debug symbols than above if required. Seems only our modules hat debuginfo at the time of the backtrace. Greetings Christian Kratzer CK Software GmbH

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by hyc＠symas.com 10 Sep '13

10 Sep '13

Michael Ströder wrote: > On Fri, 21 Sep 2012 10:43:42 -0700 Howard Chu <hyc(a)symas.com> wrote >> michael(a)stroeder.com wrote: >>> Feature request: >>> When using LDAPS or StartTLS it would be sometimes handy to retrieve the >>> LDAP server certificate over the LDAP client API. >>> >>> Opinions? >> >> And then what? I think it'd be straightforward for us to return a copy of it >> in DER binary format. What do clients need to do with it? > > In my case (web2ldap): Simply display it to the user. Probably would have been easier to just return the signature. > If it's not too much work this would be a handy feature. Added in master, please test - I have not tested any of this. -- -- 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#7686) Feature request: TLS prot/cipher retrievable with ldap_get_option()
by hyc＠symas.com 09 Sep '13

09 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.227.140.201) > > > Similar to logging at server-side (see ITS#7683) it should be possible for a > LDAP client to retrieve the TLS protocol version and cipher suites actually > negotiated by call to ldap_get_option(3) to be able to make decisions according > to local security policy. > > Added in master, tho I logged it against ITS#7683. -- -- 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

(ITS#7686) Feature request: TLS prot/cipher retrievable with ldap_get_option()
by michael＠stroeder.com 09 Sep '13

09 Sep '13

Full_Name: Version: OS: URL: Submission from: (NULL) (79.227.140.201) Similar to logging at server-side (see ITS#7683) it should be possible for a LDAP client to retrieve the TLS protocol version and cipher suites actually negotiated by call to ldap_get_option(3) to be able to make decisions according to local security policy.

1 0

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2013