- openldap-bugs - openldap.org

Re: (ITS#5938) tls.c does not conform to RFC 4513
by quanah＠zimbra.com 10 Feb '09

10 Feb '09

--On February 10, 2009 3:56:37 PM +0000 nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. > tls_o.c, but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it should not > do. Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the reference > identity to the Common Name (CN) [RFC4519] value in the leaf Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first attempting an > exact comparison on subjectAltName, and if that fails it tries a wildcard > match (which is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section which > looks at the certificate's subjectname, in which it also does a wildcard > match, although the RFC says this shouldn't be done. This is because the Cert vendors themselves don't honor the RFC's when issuing wildcard certs, and was added so that their broken wildcard certs could still be used. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5939) Missing close of file descriptor
by joakim.bentholm＠birdstep.com 10 Feb '09

10 Feb '09

Full_Name: Joakim Bentholm Version: OpenLDAP 2.4.13 OS: FreeBSD 7.0 Release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.13.255.38) The running setup: An ldap server with a socket back-end communicating with server process listening on incoming requests from the socket back-end and replying in an orderly fashing. The failure: If the server process shuts down, the socket back-end will continue to try to connect and allocating new file descriptors which will never be released. If the server process is restarted everything will work, unless the file descriptor limit have been reached, in case the ldap server have to be restart. Solution: close the file descripton The following patch solves the problem --- --- servers/slapd/back-sock/opensock.c.orig 2008-02-09 01:46:09.000000000 +0100 +++ servers/slapd/back-sock/opensock.c 2009-02-02 16:09:24.000000000 +0100 @@ -57,6 +57,7 @@ if ( connect( fd, (struct sockaddr *)&sockun, sizeof(sockun) ) < 0 ) { Debug( LDAP_DEBUG_ANY, "socket connect(%s) failed\n", sockpath ? sockpath : "<null>", 0, 0 ); + close( fd ); return( NULL ); } ---

1 0

(ITS#5938) tls.c does not conform to RFC 4513
by nick.hudson＠isode.com 10 Feb '09

10 Feb '09

Full_Name: nick hudson Version: 2.3.38 OS: linux URL: Submission from: (NULL) (62.3.217.250) I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname (although the code has been refactored in recent versions, into e.g. tls_o.c, but the same is true of the new code) I think the code is doing something that RFC 4513 says that it should not do. Specifically, ref RFC 4513 section 3.1.3 says: The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. In tls.c (and the refactored code), you can see it's first attempting an exact comparison on subjectAltName, and if that fails it tries a wildcard match (which is ok, as per section 3.1.3.1) But if no subjectAltName match is found, there's another section which looks at the certificate's subjectname, in which it also does a wildcard match, although the RFC says this shouldn't be done.

1 0

Re: (ITS#5937) Apparent mistake in ipv6 address handling in tls.c
by hyc＠symas.com 10 Feb '09

10 Feb '09

Kurt Zeilenga wrote: > On Feb 10, 2009, at 4:27 AM, hyc(a)symas.com wrote: >> Nice catch, that's been in there since 2002. Fixed in HEAD. > > I counted 5 occurs in HEAD tls*.c... 2 of those are in tls.c, which is no longer being compiled. I just haven't got around to cvs rm'ing it yet after splitting to tls2.c and the other modules. -- -- 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#5937) Apparent mistake in ipv6 address handling in tls.c
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 4:27 AM, hyc(a)symas.com wrote: > nick.hudson(a)isode.com wrote: >> Full_Name: nick hudson >> Version: 2.3.38 >> OS: linux >> URL: >> Submission from: (NULL) (62.3.217.250) >> >> >> I think there is a bug in libraries/libldap/tls.c - specifically in >> this >> section: >> >> #ifdef LDAP_PF_INET6 >> if (name[0] == '['&& strchr(name, ']')) { >> char *n2 = ldap_strdup(name+1); >> *strchr(n2, ']') = 2; >> if (inet_pton(AF_INET6, n2,&addr)) >> ntype = IS_IP6; >> LDAP_FREE(n2); >> } else >> #endif >> >> the code is attempting to detect whether part of an LDAP URL >> represents an IPv6 >> address; it passes the string to inet_pton(), after removing square >> brackets. >> But I think this line: >> >> *strchr(n2, ']') = 2; >> >> is wrong: shouldn't it be using 0 instead of 2? >> >> When testing on my local system, using the code above always >> results in >> inet_pton returning 0 (not an IPv6 address) - if I modify the >> strchr line to use >> zero instead, then inet_pton returns 1 for valid IPv6 addresses. >> >> I may be missing something - "2" seems a peculiar value to use so >> perhaps it >> does have some special significance - but I think the code as it >> stands is >> incorrect. > > Nice catch, that's been in there since 2002. Fixed in HEAD. I counted 5 occurs in HEAD tls*.c... -- Kurt

1 0

Re: (ITS#5936) test049 uses nonexistant variable SLEEP1
by hyc＠symas.com 10 Feb '09

10 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: irrelevant > URL: http://milopita.phillipoux.net/jonathan-clarke-20090210-test049.patch > Submission from: (NULL) (213.41.243.192) > > > test049 complains with: > Waiting seconds for syncrepl to receive changes... > sleep: missing operator > > The patch below corrects this. Using 10 seconds as default value, as is done > above in the test script for cn=config replication. > > > Thanks, fixed. I guess we probably should just sync up the rest of the test scripts between HEAD and RE24 after all, since we've tripped over this a few times already. -- -- 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#5937) Apparent mistake in ipv6 address handling in tls.c
by hyc＠symas.com 10 Feb '09

10 Feb '09

nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I think there is a bug in libraries/libldap/tls.c - specifically in this > section: > > #ifdef LDAP_PF_INET6 > if (name[0] == '['&& strchr(name, ']')) { > char *n2 = ldap_strdup(name+1); > *strchr(n2, ']') = 2; > if (inet_pton(AF_INET6, n2,&addr)) > ntype = IS_IP6; > LDAP_FREE(n2); > } else > #endif > > the code is attempting to detect whether part of an LDAP URL represents an IPv6 > address; it passes the string to inet_pton(), after removing square brackets. > But I think this line: > > *strchr(n2, ']') = 2; > > is wrong: shouldn't it be using 0 instead of 2? > > When testing on my local system, using the code above always results in > inet_pton returning 0 (not an IPv6 address) - if I modify the strchr line to use > zero instead, then inet_pton returns 1 for valid IPv6 addresses. > > I may be missing something - "2" seems a peculiar value to use so perhaps it > does have some special significance - but I think the code as it stands is > incorrect. Nice catch, that's been in there since 2002. Fixed in HEAD. -- -- 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#5937) Apparent mistake in ipv6 address handling in tls.c
by nick.hudson＠isode.com 10 Feb '09

10 Feb '09

Full_Name: nick hudson Version: 2.3.38 OS: linux URL: Submission from: (NULL) (62.3.217.250) I think there is a bug in libraries/libldap/tls.c - specifically in this section: #ifdef LDAP_PF_INET6 if (name[0] == '[' && strchr(name, ']')) { char *n2 = ldap_strdup(name+1); *strchr(n2, ']') = 2; if (inet_pton(AF_INET6, n2, &addr)) ntype = IS_IP6; LDAP_FREE(n2); } else #endif the code is attempting to detect whether part of an LDAP URL represents an IPv6 address; it passes the string to inet_pton(), after removing square brackets. But I think this line: *strchr(n2, ']') = 2; is wrong: shouldn't it be using 0 instead of 2? When testing on my local system, using the code above always results in inet_pton returning 0 (not an IPv6 address) - if I modify the strchr line to use zero instead, then inet_pton returns 1 for valid IPv6 addresses. I may be missing something - "2" seems a peculiar value to use so perhaps it does have some special significance - but I think the code as it stands is incorrect.

1 0

(ITS#5936) test049 uses nonexistant variable SLEEP1
by jclarke＠linagora.com 10 Feb '09

10 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: irrelevant URL: http://milopita.phillipoux.net/jonathan-clarke-20090210-test049.patch Submission from: (NULL) (213.41.243.192) test049 complains with: Waiting seconds for syncrepl to receive changes... sleep: missing operator The patch below corrects this. Using 10 seconds as default value, as is done above in the test script for cn=config replication.

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 10 Feb '09

10 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Thanks for checking this out. > >> If you want this to work you'll have to provide both the build >> directory and your installed directory in your -rpath. > > Doesn't sound good either. Then I presume the installed binaries may > later use libraries from a test build. Probably. You can of course edit the relink commands in the wrapper to eliminate the build runpath, but it's a lot of manual intervention no matter how you slice it. > >> The symlinks would then help a little, because you only need to set >> one build rpath instead of 3. Go ahead and restore the build rules in >> your source tree to set the symlinks if you want them. At the moment >> it looks like they're not generally useful, and I'm tired of >> committing/reverting, so I'm not touching those files any more today. > > I don't have time for this now either, but I'll hopefully get to it > soon. I wonder if a fix will be to revert the recent libtool upgrade:-( > > Of course it may be that this situation has existed for ages but I only > noticed because of the missing ldap_pvt_search symbol. > The build rules were changed in OL 2.1, it's been like this for ages... -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 10 Feb '09

10 Feb '09

Thanks for checking this out. > If you want this to work you'll have to provide both the build > directory and your installed directory in your -rpath. Doesn't sound good either. Then I presume the installed binaries may later use libraries from a test build. > The symlinks would then help a little, because you only need to set > one build rpath instead of 3. Go ahead and restore the build rules in > your source tree to set the symlinks if you want them. At the moment > it looks like they're not generally useful, and I'm tired of > committing/reverting, so I'm not touching those files any more today. I don't have time for this now either, but I'll hopefully get to it soon. I wonder if a fix will be to revert the recent libtool upgrade:-( Of course it may be that this situation has existed for ages but I only noticed because of the missing ldap_pvt_search symbol. -- Hallvard

1 0

Re: (ITS#5893) test scripts should stop immediately if slapd crashed
by ando＠sys-net.it 10 Feb '09

10 Feb '09

Howard Chu wrote: > Pierangelo Masarati wrote: >> hyc(a)symas.com wrote: >> >>> I saw that, but it seems that multiple -i options work. >>> -i !xx -i yy >> >> Yes, it works. The test becomes waaaaaay too verbose, though. It'd be >> nicer to have the possibility to limit the error message to the first >> occurrence, when it is intended. > > Yes, I also patched slapd-bind.c in my tree, forgot to mention that: > @@ -344,7 +348,7 @@ > /* if ignore.. */ > if ( first ) { > /* only log if first occurrence */ > - if ( force < 2 || first == 1 ) { > + if ( first == 1 ) { > tester_ldap_error( ld, "ldap_sasl_bind_s", NULL ); > } > rc = LDAP_SUCCESS; I've added another modifier, "*", that makes testers ignore errors and only log the first occurrence. I'm about to commit it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5893) test scripts should stop immediately if slapd crashed
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> I saw that, but it seems that multiple -i options work. >> -i !xx -i yy > > Yes, it works. The test becomes waaaaaay too verbose, though. It'd be > nicer to have the possibility to limit the error message to the first > occurrence, when it is intended. Yes, I also patched slapd-bind.c in my tree, forgot to mention that: @@ -344,7 +348,7 @@ /* if ignore.. */ if ( first ) { /* only log if first occurrence */ - if ( force < 2 || first == 1 ) { + if ( first == 1 ) { tester_ldap_error( ld, "ldap_sasl_bind_s", NULL ); } rc = LDAP_SUCCESS; -- -- 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#5893) test scripts should stop immediately if slapd crashed
by ando＠sys-net.it 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > I saw that, but it seems that multiple -i options work. > -i !xx -i yy Yes, it works. The test becomes waaaaaay too verbose, though. It'd be nicer to have the possibility to limit the error message to the first occurrence, when it is intended. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

ando(a)sys-net.it wrote: > This won't probably be as easy as I expected: back-meta does not check, > parse or return entry controls. This needs to be fixed as well. My fault: back-meta does. However, something strange is happening: - in some cases, while looping for attribute values, back-meta incorrectly treates entry controls (right after the SearchResultEntry message) as yet another attribute name/values set - in other cases things just go fine I'm trying to modify the code in order to compute the size of the SearchResultEntry portion of the message, but again, in some cases, the size is computed incorrectly: the computed length is 4 octets shorter than what's actually in the packet. One issue seems to be related to the fact that when ber_skip_tag() checks if the length it's computed fits in the ber by calling ber_pvt_ber_remaining(), it doesn't count that earlier calls to ber_read() moved the ber_ptr forward. The original ber_ptr should be saved. I don't believe messages are encoded incorrectly, so I must be doing something wrong in decoding them... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5613) slapd determines hostname by PTR even if host url defined, breaking ServerID
by hyc＠symas.com 10 Feb '09

10 Feb '09

joe(a)julianfamily.org wrote: > Full_Name: Joe Julian > Version: 2.4.10 > OS: Linux (Fedora 7 distribution) > URL: > Submission from: (NULL) (68.178.24.202) > > > Description of problem: > slapd is called with "-h ldap://ldap1.domain.dom" where ldap1 is a CNAME for > the > actual server name "moe.domain.dom" and "-h ldap://ldap2.domain.dom" for > "curly.domain.dom". > > The cn=config entries for olcServerID are "1 ldap://ldap1.domain.dom" and "2 > ldap://ldap2.domain.dom" > > In config_generic (bconfig.c) case CFG_SERVERID lud->lud_host is compared with > global_host. As the PTR record for moe is moe.domain.dom and not > ldap1.domain.dom, moe does not get assigned a serverID. The same is true for > curly. > Expected results: > the serverID should be selected (in part) based on the "-h" url configuration > matching an olcServerID entry The listener URLs specified with -h are now being compared. The fix is in HEAD, please test. Thanks. -- -- 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#5853) LDAP search crashes when chasing multiple referrals
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > And yet another approach is simply to bump up each lconn's refcnt, the same > way request.c:ldap_new_connection() does, to prevent them from getting freed > prematurely. This latter approach would be simplest, except it requires > calling ldap_free_connection() to actually decrement the refcnt, and that > requires more mutex manipulation for the libldap_r version. (I haven't looked > too deeply into the lock dependencies yet, it may actually be simpler.) I opted for this approach, now checked into HEAD. Please test. -- -- 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#5893) test scripts should stop immediately if slapd crashed
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: karlsruhe >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> Currently test039-glue-ldap-concurrency fails with a lot of these messages (see >>> below). Maybe the test scripts could be modified to detect this situation and >>> stop immediately. >> Normally the tester programs will stop immediately on any error. test036 and >> test039 invoke slapd-tester with -FF which causes slapd-bind to ignore errors. >> (Note that test008 doesn't use -FF.) >> >> Seems to me that test036/039 would both work fine if they just added -i >> INVALID_CREDENTIALS to the TESTER invocation, instead of using -FF. >> >> Ando, what do you think? > > Not right now: -i is already used with negation ("!"). Negation needs > to move on a per-value basis, or something like that (if I0m reading > that code fine). I'll look at it, maybe later. I saw that, but it seems that multiple -i options work. -i !xx -i yy -- -- 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#5893) test scripts should stop immediately if slapd crashed
by ando＠sys-net.it 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: karlsruhe >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.100.169) >> >> >> Currently test039-glue-ldap-concurrency fails with a lot of these messages (see >> below). Maybe the test scripts could be modified to detect this situation and >> stop immediately. > > Normally the tester programs will stop immediately on any error. test036 and > test039 invoke slapd-tester with -FF which causes slapd-bind to ignore errors. > (Note that test008 doesn't use -FF.) > > Seems to me that test036/039 would both work fine if they just added -i > INVALID_CREDENTIALS to the TESTER invocation, instead of using -FF. > > Ando, what do you think? Not right now: -i is already used with negation ("!"). Negation needs to move on a per-value basis, or something like that (if I0m reading that code fine). I'll look at it, maybe later. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by hyc＠symas.com 09 Feb '09

09 Feb '09

This is some extremely ugly code. My first instinct is to rewrite it to eliminate the recursion but I have a feeling that may be too drastic a change. Another thought is to alter wait4msg/try_read1msg's parameter list to specify which lconn to start from, and order the list such that the recursive calls can only iterate over the newest lconn structures. That would prevent them from freeing lconns that are currently being referenced by a prior caller. (That would also prevent them from parsing any received data that's ready on other connections, until the Bind on the new referral connection completes. So this may needlessly serialize some work and decrease overall throughput when references are interleaved in a larger result set.) And yet another approach is simply to bump up each lconn's refcnt, the same way request.c:ldap_new_connection() does, to prevent them from getting freed prematurely. This latter approach would be simplest, except it requires calling ldap_free_connection() to actually decrement the refcnt, and that requires more mutex manipulation for the libldap_r version. (I haven't looked too deeply into the lock dependencies yet, it may actually be simpler.) -- -- 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#5853) LDAP search crashes when chasing multiple referrals
by hyc＠symas.com 09 Feb '09

09 Feb '09

Judging from the stack trace, this appears to be the same as #5743. Since there's more info here, I'll close the older one as a dup of this one. -- -- 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#5925
by hyc＠symas.com 09 Feb '09

09 Feb '09

tchemineau(a)linagora.com wrote: > I confirm that we can not create subordinate configs dynamically in > cn=config now. I used a previously build version to realize it, just > for testing it. > > There is still errors with slaptest, even on slapd.d. Same errors when > I want to start OpenLDAP. Thanks, now fixed. -- -- 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#5893) test scripts should stop immediately if slapd crashed
by hyc＠symas.com 09 Feb '09

09 Feb '09

michael(a)stroeder.com wrote: > Full_Name: karlsruhe > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.100.169) > > > Currently test039-glue-ldap-concurrency fails with a lot of these messages (see > below). Maybe the test scripts could be modified to detect this situation and > stop immediately. Normally the tester programs will stop immediately on any error. test036 and test039 invoke slapd-tester with -FF which causes slapd-bind to ignore errors. (Note that test008 doesn't use -FF.) Seems to me that test036/039 would both work fine if they just added -i INVALID_CREDENTIALS to the TESTER invocation, instead of using -FF. Ando, what do you think? -- -- 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#5935) segfault in syncrepl.c when replacing olcSyncrepl values by syncrepl on cn=config
by hyc＠symas.com 09 Feb '09

09 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS 5.2 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi all, > > We have encountered a segfault that occurs in syncrepl.c, on line 1449 (from a > checkout of RE24 today). > > This occurs during replication of cn=config, by a thread in do_syncrepl on > rid=999. Syncrepl pulls in new values for olcSyncRepl on cn=config. This deletes > the configuration for rid=999, and adds configuration for rid=001 and rid=002. Thanks for the report, now fixed in HEAD. > > Some debugging (lots) showed the following. > > This thread enters syncrepl_config() 3 times: > 1) Delete rid=999. This detects this syncrepl is running, and sets si->si_ctype > = 0 (as described in the comments in syncrepl.c line 4358). si is not freed, > since it's running. The c->be->be_syncinfo->si_cookieState is freed (line > 4564). > 2) Add rid=001 > 3) Add rid=002 > > Back in syncrepl.c on line 1449, the "final delete cleanup" looks for it's own > si in be->be_syncinfo. It of course doesn't find it (the config is deleted), and > segfaults when sip = null. > > We have tried changing these lines to: > for ( sip =&be->be_syncinfo; sip != NULL || *sip != si; sip =&(*sip)->si_next > ); > if (sip) { > *sip = si->si_next; > } > > However, we then encounter another segfault on line 1448, involving > be->be_syncinfo->si_cookieState, which was freed... It's a bit too much for us > at this point, do you have any more ideas? > > > -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Michael Ströder wrote: > As said I'm really concerned about security aspects: Because if the > hostname in the LDAP URL is absent there's absolutely no possibility to > check for DNS spoofing and the LDAP client would possibly happily send > its credentials to a rogue server, even with TLS or Kerberos. Think > twice before implementing this. > > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. But stuffing this in ldap_initialize(3) has the great advance of allowing to inject this feature in clients without the need to modify them, just reconfiguring. The use of a URL extension should make it clear that one intends to use the feature, and avoid unintentional (e.g. misconfiguration) uses. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs