openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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 10 Feb '09

10 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 10 Feb '09

10 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 10 Feb '09

10 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 10 Feb '09

10 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 10 Feb '09

10 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

Re: authzTo ACL check for wrong principal (ITS#5555)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Gavin Henry wrote: >> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: >> >>> Thus I think my original report was wrong. This is a documentation >>> issue, not a bug. >> I have uploaded a suggested set of patches to make the behaviour >> clearer: >> >> ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch >> >> The patch is against 2.4.10 >> >> It might be better still to factor out the concept of proxy >> authorisation and its control from the SASL authz mechanism, as it >> applies also to the LDAP Proxied Authorization Control. >> I have not done this as I was unsure where best to put it. > > Hi Ando, > > If you get a chance at some point, could you review this patch and I'll apply it > etc. After a quick look, it seems to be a good starting point. I'd be a little bit more careful about wording: "proxyAuthz" should probably be "proxied authorization"; the first time it is mentioned, a reference to RFC4370 should be present, both in slapd.access(5) and in the Admin Guide (as in the SASL section). Also, in the contribution to the Admin Guide it is sometimes referred to as the "proxy facility"; I'd rather use "proxied authorization facility" or better "proxied authorization control". Finally, the patch seems to correctly explain what is required in order to authorize. I'd add a strong comment on the importance to protect authzFrom and especially authzTo from malicious writes, that could result in lesser privileged identities to modify their own entry in order to be able to self-authorize as higher privileged identities. Administrators should be warned as they start reading about this feature. 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#5934) NULL pointer usage in ldap_new_connection(), causes segmentation fault
by hyc＠symas.com 09 Feb '09

09 Feb '09

bplank(a)gta.com wrote: > Full_Name: Brad Plank > Version: 2.4.13 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/brad-plank-090209.patch > Submission from: (NULL) (199.120.225.110) > Thanks for the report, now fixed in HEAD and RE24. > NULL pointer usage in: > LDAPConn * > ldap_new_connection( LDAP *ld, LDAPURLDesc **srvlist, int use_ldsb, > int connect, LDAPreqinfo *bind ) > > ... > if ( lc->lconn_server->lud_exts ) { > ... > > The below patch is to fix this issue, since the pointer "lconn_server" should > only be used when "connect" is non-zero: > > ================================================================== > > --- libraries/libldap/request.c.orig 2008-11-07 20:15:17.000000000 -0500 > +++ libraries/libldap/request.c 2009-02-09 11:01:56.000000000 -0500 > @@ -452,9 +452,9 @@ ldap_new_connection( LDAP *ld, LDAPURLDe > ldap_pvt_thread_mutex_unlock(&ld->ld_conn_mutex ); > #endif > > - if ( lc->lconn_server->lud_exts ) { > -#ifdef HAVE_TLS > if ( connect ) { > +#ifdef HAVE_TLS > + if ( lc->lconn_server->lud_exts ) { > int rc, ext = find_tls_ext( lc->lconn_server ); > if ( ext ) { > LDAPConn *savedefconn; > > ================================================================== > > I, Brad Plank, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs