- openldap-bugs - openldap.org

(ITS#5200) Wrong maxderefdepth doc or default
by h.b.furuseth＠usit.uio.no 24 Oct '07

24 Oct '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf(5) and slapd-config(5) say MaxDerefDepth defaults to 1, but include/ldap_defaults.h says #define SLAPD_DEFAULT_MAXDEREFDEPTH 15.

1 0

(ITS#5199) slapd sometimes hangs with back-sql
by david＠schmitt.edv-bus.at 24 Oct '07

24 Oct '07

Full_Name: David Schmitt Version: 2.3.38 OS: Debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.138.34) Hi! I have OSX clients authenticating via slapd against my postgres database. Once every fortnight slapd stops responding to requests. I got this backtrace out of it: 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 (gdb) bt full #0 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004230d2 in slapd_daemon () at /root/tmp/openldap2.3-2.3.38/servers/slapd/daemon.c:2579 listener_tid = 1082132832 rc = 0 #2 0x000000000041665f in main (argc=5, argv=0x7fff748e4288) at /root/tmp/openldap2.3-2.3.38/servers/slapd/main.c:859 save_errno = <value optimized out> fp = (FILE *) 0x6a4f70 i = <value optimized out> no_detach = 0 rc = 1 urls = <value optimized out> username = 0x605030 "gidNumber" groupname = 0x605010 "\226{P7(+" sandbox = 0x0 syslogUser = 160 configfile = <value optimized out> configdir = <value optimized out> serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" (gdb) When testing with ldapsearch, the client connects, but doesn't receive any data. This is running on a 2.6.21-2-vserver-amd64 kernel, within a vserver container.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 24 Oct '07

24 Oct '07

jclarke(a)linagora.com wrote: > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! It seems to work correctly, but there seems to be an easier fix: just NULL out the pointer to lset/rset, respectively. I'm patching the code this way, please test if you get a chance. Thanks, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5198) wrong SQL-Statements in Back-SQL
by ando＠sys-net.it 24 Oct '07

24 Oct '07

peter.gietz(a)daasi.de wrote: > This bug report was given to me at the OpenLDAP booth on the Systems in Munich. > > SQL search-statements are wrong because of a strange OR condition: > "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entry_objclasses.oc_name='" > > So instead of a subset, all data are included in the response. It is not a bug, but rather an easy means to indicate that the whole data should be returned to the frontend in order to filter it the LDAP way, since sub-classing might be involved. If that user doesn't want searches for (objectClass=person) to return objects with objectClass=inetOrgPerson, then he shouldn't be using LDAP. > Thats what the > guy, who was too lazy to make the bug report himself told me. He also told me > that he patched his code (by deleting the condition (2=2) and is happy for > now. Well, you see: open source software makes people happy. As a side note, usually, well-designed RDBMSes understand that 2=2 is always true and do not proceed any further in evaluating other clauses in the OR. For those RDBMSes this causes a performance degradation (and, I insist, it would be the RDBMS' fault) the only **improvement** to OpenLDAP's back-sql (no bug) could consist in detecting that condition ourselves and omit that part of the WHERE clause entirely. But this would probably require to rewrite the filter translation layer, and it's not something I plan to do any soon (unless rewarded enough to distract me from other issues, I mean). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by hyc＠symas.com 23 Oct '07

23 Oct '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > ldap_pvt_thread_pool_query is referenced even if --without-threads. I believe > this is as simple as... Thanks for the report. > > --- result.c~ 2007-10-23 09:53:36.646614000 -0400 > +++ result.c 2007-10-23 09:53:23.640874000 -0400 > @@ -743,12 +743,14 @@ > return LDAP_SIZELIMIT_EXCEEDED; > } > > +#ifndef NO_THREADS > /* Every 64 entries, check for thread pool pause */ > if (( rs->sr_nentries & 0x3f == 0x3f ) && > ldap_pvt_thread_pool_query( &connection_pool, > LDAP_PVT_THREAD_POOL_PARAM_PAUSING, &i ) == 0 && i ) { > return LDAP_BUSY; > } > +#endif > > rs->sr_type = REP_SEARCH; > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5198) wrong SQL-Statements in Back-SQL
by peter.gietz＠daasi.de 23 Oct '07

23 Oct '07

Full_Name: Peter Gietz Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.154.95.209) This bug report was given to me at the OpenLDAP booth on the Systems in Munich. SQL search-statements are wrong because of a strange OR condition: "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" So instead of a subset, all data are included in the response. Thats what the guy, who was too lazy to make the bug report himself told me. He also told me that he patched his code (by deleting the condition (2=2) and is happy for now. If you think this is a bug, please repair. I found this in the source code (.../slapd/back-sql/search.c (lines 780-805): (not sure if this is the only occurance) /* * "structural" objectClass inheritance: * - a search for "person" will also return * "inetOrgPerson" * - a search for "top" will return everything */ if ( is_object_subclass( oc, bsi->bsi_oc->bom_oc ) ) { static struct berval ldap_entry_objclasses = BER_BVC( "ldap_entry_objclasses" ); backsql_merge_from_tbls( bsi, &ldap_entry_objclasses ); backsql_strfcat_x( &bsi->bsi_flt_where, bsi->bsi_op->o_tmpmemctx, "lbl", (ber_len_t)STRLENOF( "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" /* ')) */ ), "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" /* ')) */, &bsi->bsi_oc->bom_oc->soc_cname, (ber_len_t)STRLENOF( /* ((' */ "'))" ), /* ((' */ "'))" ); bsi->bsi_status = LDAP_SUCCESS; rc = 1; goto done; } break; }

1 0

(ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by richton＠nbcs.rutgers.edu 23 Oct '07

23 Oct '07

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) ldap_pvt_thread_pool_query is referenced even if --without-threads. I believe this is as simple as... --- result.c~ 2007-10-23 09:53:36.646614000 -0400 +++ result.c 2007-10-23 09:53:23.640874000 -0400 @@ -743,12 +743,14 @@ return LDAP_SIZELIMIT_EXCEEDED; } +#ifndef NO_THREADS /* Every 64 entries, check for thread pool pause */ if (( rs->sr_nentries & 0x3f == 0x3f ) && ldap_pvt_thread_pool_query( &connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PAUSING, &i ) == 0 && i ) { return LDAP_BUSY; } +#endif rs->sr_type = REP_SEARCH;

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 23 Oct '07

23 Oct '07

I said: > I'll patch and report back. Apologies for the delaying in confirming... Yep, this fixed the problem I was seeing. Many thanks Toby

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

On Dienstag, 23. Oktober 2007, Howard Chu wrote: > rhafer(a)suse.de wrote: > > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > >> For the records: I seem to be ble to consistently reproduce the issue > >> when running slapd under valgrind; > > > > Thanks, that seems to do the trick for me as well. > > Funny, even running either slapd.1 or slapd.2 under valgrind, it still > succeeds for me. > > >> I haven't seen it yet when running the test > >> regularly (single CPU i386, recently). > > Looking at Gavin's testrun files, diffing slapd.2.log against a successful > run, the main difference I see is that on the failed run some queries get > added into the cache later than in the successful run. As such, the > difference comes down to whether the pcache thread gets to run before the > next query arrives or not. So, still non-deterministic and not really a big > deal. Ok, so it's most probably really the same issue as in ITS#5114 Followup 20. The non-deterministic behaviour got introduced by moving the actual caching of the entries to the cleanup handler. As a result of this, the ldapsearch commands in the test suite finishes (and the next operations start) before the data has been completely cached. Which I think is not a bug. Any ideas how we could fix the test without introducing any sleep calls to it? -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by hyc＠symas.com 23 Oct '07

23 Oct '07

rhafer(a)suse.de wrote: > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: >> For the records: I seem to be ble to consistently reproduce the issue when >> running slapd under valgrind; > Thanks, that seems to do the trick for me as well. Funny, even running either slapd.1 or slapd.2 under valgrind, it still succeeds for me. >> I haven't seen it yet when running the test >> regularly (single CPU i386, recently). Looking at Gavin's testrun files, diffing slapd.2.log against a successful run, the main difference I see is that on the failed run some queries get added into the cache later than in the successful run. As such, the difference comes down to whether the pcache thread gets to run before the next query arrives or not. So, still non-deterministic and not really a big deal. -- -- Howard Chu Chief Architect, 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#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

As discussed on committers, I have disabled the failing part of the test for now in RE24. (Should be re-enabled when the root-cause of this problem is fixed) -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > For the records: I seem to be ble to consistently reproduce the issue when > running slapd under valgrind; Thanks, that seems to do the trick for me as well. > I haven't seen it yet when running the test > regularly (single CPU i386, recently). -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 23 Oct '07

23 Oct '07

Ralf Haferkamp wrote: > Btw, could you attach your pcache configuration to this bug? It's on the ticket already Ralf: ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz -- 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

Re: (ITS#5191) Corrupted control value when using pagedresults with subordinate database
by ando＠sys-net.it 23 Oct '07

23 Oct '07

> When using pagedresults with a subordinate database, the control value of > the > returned searchResDone is corrupted. AFAIK, paged results is not supposed to work with glued databases, as its current implementation in both back-bdb/back-hdb and back-sql relies on internal properties of the storage to keep track of the state of a search. The most appropriate behavior would be to ignore the control, if not critical, or reject the operation, if critical. I take this ITS as an action to prevent paged results from working when impacting more than one glued database. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ando＠sys-net.it 23 Oct '07

23 Oct '07

For the records: I seem to be ble to consistently reproduce the issue when running slapd under valgrind; I haven't seen it yet when running the test regularly (single CPU i386, recently). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 22 Oct '07

22 Oct '07

Btw, could you attach your pcache configuration to this bug? On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote: [..] > > > > I just did the same on my x86_64 dual core. Result: 1 failure and 99 > > passes. > > Might be that this bug is better reproducable on a single core machine. > > But at > > least I was able to reproduce it now. > > I can run the same command above on a x86_64 dual core on Monday, as I'm > away on business the rest of the week. > > >> Very strange.... > > > > I have fixed a very similar issue recently (at least I thought I fixed > > it :| ). I'll take a closer look tomorrow. -- Ralf

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com 22 Oct '07

22 Oct '07

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Just reproduced it. Out of locks (so of course configure more), then >> "Accessing a corrupted shared library". Will file a separate ITS, it >> doesn't sound like slapadd in a clean directory should need 1000+ locks. > > ...yes it should, it was a case of writing an entry with many values > in an indexed attribute - after the index was big enough that presumably > few of the new values' hashes ended up on the same DB page. So, it's > just a spurious scary error message afterwards from BerkeleyDB. > The "Accessing a corrupted shared library" message occurs on Linux because it's logging an LDAP result code (80, LDAP_OTHER) as a system errno code. Probably ought to change that... -- -- Howard Chu Chief Architect, 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#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 22 Oct '07

22 Oct '07

I wrote: > Just reproduced it. Out of locks (so of course configure more), then > "Accessing a corrupted shared library". Will file a separate ITS, it > doesn't sound like slapadd in a clean directory should need 1000+ locks. ...yes it should, it was a case of writing an entry with many values in an indexed attribute - after the index was big enough that presumably few of the new values' hashes ended up on the same DB page. So, it's just a spurious scary error message afterwards from BerkeleyDB. -- Regards, Hallvard

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 22 Oct '07

22 Oct '07

hyc(a)symas.com writes: > These are backend-specific considerations. Feel free to file an ITS > against the slapd-bdb(5) manpage if you wish. Might as well be this one. "Need to document what you are explaining here." Probably mostly in the Admin Guide with a few notes in the manpage. > Any operation will acquire a lock for every single DB page it > touches. (...) I don't think that can be quite right. A search which traverses the database would need an awful lot of locks. Unless for the entries it acquires and then releases the locks for one entry at a time. > The more work that an operation needs to do, the more pages > it will touch, the more locks it will need. (...) Another item would be entries needed to evaluate access controls, I assume. >> Sleepycat messages can be scary. I came from the slapadd "wrong dynamic >> library" or message or whatever it was which the mailinglist says is >> cured with more locks & lockers, so I increased those and just got >> another error message (this ITs). So apparently, something still wrong. > > I'm not familiar with that message or advice. Just reproduced it. Out of locks (so of course configure more), then "Accessing a corrupted shared library". Will file a separate ITS, it doesn't sound like slapadd in a clean directory should need 1000+ locks. http://www.openldap.org/lists/openldap-software/200607/msg00305.html >> "Not configured for the locking subsystem" sounded like a permanent >> problem with the database build, not that it would get "reconfigured" >> to support locking when needed. Hence this report. Oh well. > > The message said The Environment is not configured for locking. It > didn't say the BDB library. Yes, that's what I meant. The database, with its enviroment, I just built with slapadd. > Really there's nothing mystical or spooky here, and if you've actually > read the BDB documentation you'll know what The Environment refers > to. If you're using back-[bh]db without having read the BDB > documentation, despite all the recommendations to do so, you deserve > to be scared. I've read it. -- Regards, Hallvard

1 0

(ITS#5196) Documentation should indicate that slurpd is deprecated
by bgmilne＠staff.telkomsa.net 22 Oct '07

22 Oct '07

Full_Name: Buchan Milne Version: REL_ENG_2_3 (post-2.3.38) OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) It is well known that slurpd is deprecated, and it has been removed from 2.4. However, many questions arise in various support fora (case in point, #ldap on irc.freenode.net) about setting up slurpd, and the documentation still covers slurpd, without noting that it is deprecated (which probably contributes to continued use of slurpd, even on 2.3). A notice should be placed at least in the following places to this effect: -slurpd(8) -Admin guide chapter 14 -replica section of slapd.conf(5) -slapd.replog(5)

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com 21 Oct '07

21 Oct '07

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> quanah(a)zimbra.com writes: >>>> You have to run slapd at least once before using the db_stat tool >>>> after using slapadd -q. This is a known feature of using -q. >>> Ah, need doc fix in slapadd.8 then. >> What exactly are you trying to do? > > Playing around, mostly. > >> slapadd -q disables locking, > > I don't see that in the doc. It's reasonable to infer, except I have no > idea why even slapadd (without -q) needs so many. I couldn't find an > explanation of what does use locks and lockers (FAQ file 893 doesn't > say), thus not how many I will need and which of these limits is fatal > if I have too few. Can experiment to find out the latter, of course. These are backend-specific considerations. Feel free to file an ITS against the slapd-bdb(5) manpage if you wish. In back-[bh]db there are typically up to two transactions per operation, and each transaction uses a single locker. There's also a single reader locker per thread. So at most you need 3 lockers per configured server thread. The BDB default of 1000 is generally more than enough. Any operation will acquire a lock for every single DB page it touches. The more work that an operation needs to do, the more pages it will touch, the more locks it will need. If you write an entry that has many indexed attributes, or if you have substring indices on attributes with lengthy values, you will need many locks in a single operation. While the number of pages simultaneously held open will depend on the actual distribution of data in the database, an operation will generally need at least one lock per DB file. So, one for a dn2id lookup, one for an id2entry lookup, and one for each defined index. In most cases that's all, but substring indices will generally need a number of locks proportional to the length of the strings being indexed. > Sleepycat messages can be scary. I came from the slapadd "wrong dynamic > library" or message or whatever it was which the mailinglist says is > cured with more locks & lockers, so I increased those and just got > another error message (this ITs). So apparently, something still wrong. I'm not familiar with that message or advice. > "Not configured for the locking subsystem" sounded like a permanent > problem with the database build, not that it would get "reconfigured" to > support locking when needed. Hence this report. Oh well. The message said The Environment is not configured for locking. It didn't say the BDB library. Really there's nothing mystical or spooky here, and if you've actually read the BDB documentation you'll know what The Environment refers to. If you're using back-[bh]db without having read the BDB documentation, despite all the recommendations to do so, you deserve to be scared. >> so of course there's nothing for db_stat -c to report. There's no >> breakage here. > -- -- Howard Chu Chief Architect, 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#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 21 Oct '07

21 Oct '07

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> quanah(a)zimbra.com writes: >>> You have to run slapd at least once before using the db_stat tool >>> after using slapadd -q. This is a known feature of using -q. >> >> Ah, need doc fix in slapadd.8 then. > > What exactly are you trying to do? Playing around, mostly. > slapadd -q disables locking, I don't see that in the doc. It's reasonable to infer, except I have no idea why even slapadd (without -q) needs so many. I couldn't find an explanation of what does use locks and lockers (FAQ file 893 doesn't say), thus not how many I will need and which of these limits is fatal if I have too few. Can experiment to find out the latter, of course. Sleepycat messages can be scary. I came from the slapadd "wrong dynamic library" or message or whatever it was which the mailinglist says is cured with more locks & lockers, so I increased those and just got another error message (this ITs). So apparently, something still wrong. "Not configured for the locking subsystem" sounded like a permanent problem with the database build, not that it would get "reconfigured" to support locking when needed. Hence this report. Oh well. > so of course there's nothing for db_stat -c to report. There's no > breakage here. -- Hallvard

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 19 Oct '07

19 Oct '07

russell-openldap(a)stuart.id.au wrote: > I am trying to insist that connections during sasl auth operations are > encrypted. Ie, that this works: > > access to attrs=userPassword > by tls_ssf=128 ssf=128 anonymous auth > by * none > > It does work for a simple bind. But for a sasl bind it fails, and this telltale > appears in the log: > > slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 > > I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: I suppose that may be a legitimate bug, but this isn't really the correct fix. slap_auxprop_lookup is doing an internal search, so there is no network to speak of. In SSF terms it would have an SSF of "infinity". > diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c > openldap2.3-2.3.30.new/servers/slapd/sasl.c > --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 > +1000 > +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 > +1000 > @@ -384,6 +384,7 @@ > op.ors_slimit = 1; > op.ors_filter = &generic_filter; > op.ors_filterstr = generic_filterstr; > + op.o_authz = conn->c_authz; > /* FIXME: we want all attributes, right? */ > op.ors_attrs = NULL; > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 18 Oct '07

18 Oct '07

Full_Name: Russell Stuart Version: 2.3.30 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.15.201.110) I am trying to insist that connections during sasl auth operations are encrypted. Ie, that this works: access to attrs=userPassword by tls_ssf=128 ssf=128 anonymous auth by * none It does work for a simple bind. But for a sasl bind it fails, and this telltale appears in the log: slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c openldap2.3-2.3.30.new/servers/slapd/sasl.c --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 +1000 +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 +1000 @@ -384,6 +384,7 @@ op.ors_slimit = 1; op.ors_filter = &generic_filter; op.ors_filterstr = generic_filterstr; + op.o_authz = conn->c_authz; /* FIXME: we want all attributes, right? */ op.ors_attrs = NULL;

1 0

(ITS#5194) tpool lockup in RE_24
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) Using latest RE_24, test050 locked up on me. slapd backtrace shows: (gdb) info threads 1 Thread 46912516103168 (LWP 8947) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaaabc72e in ldap_pvt_thread_pool_resume (tpool=<value optimized out>) at tpool.c:703 #4 0x000000000041d8d5 in config_back_modify (op=0x7fffeb28cc50, rs=0x7fffeb28cdc0) at bconfig.c:4710 #5 0x00002aaaac3d5944 in syncprov_checkpoint (op=0x7fffeb28cec0, rs=<value optimized out>, on=0x1b8df9d0) at syncprov.c:1318 #6 0x00002aaaac3d5f02 in syncprov_db_close (be=0x1b7a6440, cr=<value optimized out>) at syncprov.c:2660 #7 0x0000000000485578 in over_back_response (op=0x1b7c57c0, rs=0x1b7c57c0) at backover.c:234 #8 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x00002aaaaaabc72e in ldap_pvt_thread_pool_resume (tpool=<value optimized out>) at tpool.c:703 703 ldap_pvt_thread_mutex_lock(&pool->ltp_mutex); (gdb) l 698 pool = *tpool; 699 700 if (pool == NULL) 701 return(0); 702 703 ldap_pvt_thread_mutex_lock(&pool->ltp_mutex); 704 pool->ltp_pause = 0; 705 if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING) 706 ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); 707 ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex);

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs