openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 06 Sep '10

06 Sep '10

> --On Sunday, September 05, 2010 9:19 PM +0200 masarati(a)aero.polimi.it > wrote: > > >>> /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H >>> ldap://...:3268 >>> -x -E >>> deref=member:mail "(CN=test)" mail > >>From the ITS. Only thing I removed was binddn, password, and hostname. > Note that the same search against OpenLDAP also segfaults, so it is not a > server side issue. It is clearly a client-side issue: the core dump appears while cooking the control's value. Your backtrace shows a failure on strlen() being passed an invalid string. The string appears invalid to gdb as well, as it fails to show the contents of the string's pointer. Using valgrind with Linux I notice a memory allocation error. Checking... p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 05 Sep '10

05 Sep '10

--On Sunday, September 05, 2010 9:19 PM +0200 masarati(a)aero.polimi.it wrote: >> /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 >> -x -E >> deref=member:mail "(CN=test)" mail >From the ITS. Only thing I removed was binddn, password, and hostname. Note that the same search against OpenLDAP also segfaults, so it is not a server side issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Mac OSX 10.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > When querying AD from a mac, we found that we can segfault ldapsearch. > This > segfault does not happen when running the same query from linux. Here is > the > backtrace: > > (gdb) thr apply all bt full > > Thread 1 (core thread 0): > #0 0x00007fff80697180 in strlen () > No symbol table info available. > #1 0x000000010008ae22 in ber_put_string (ber=0x100401480, > str=0x686372616573 > <Address 0x686372616573 out of bounds>, tag=18446744073709551615) at > encode.c:273 Something seems to be wrong with the parsing of the deref control in ldapsearch.c; can you provide the command-line? Thanks, p. > No locals. > #2 0x000000010008be20 in ber_printf (ber=0x100401480, fmt=0x10005f5e4 > "s{") at > encode.c:575 > ap = {{ > gp_offset = 24, > fp_offset = 48, > overflow_arg_area = 0x7fff5fbfeb00, > reg_save_area = 0x7fff5fbfea40 > }} > s = 0x686372616573 <Address 0x686372616573 out of bounds> > ss = (char **) 0x0 > bv = (struct berval *) 0x0 > bvp = (struct berval **) 0x7fff8069dc3b > rc = 0 > i = 584234 > len = 140734799800880 > #3 0x00000001000586d8 in ldap_create_deref_control_value (ld=0x100401130, > ds=0x100400130, value=0x100016a20) at deref.c:68 > j = 1 > ber = (BerElement *) 0x100401480 > tag = 18 > i = 1 > __func__ = "\000\000\000\000\000\000\000Critical extension is una" > #4 0x0000000100003a28 in main (argc=13, argv=0x7fff5fbff4f8) at > ldapsearch.c:1090 > i = 0 > filtpattern = 0x7fff5fbff739 "(CN=SE-EMEA-OEM)" > attrs = (char **) 0x7fff5fbff558 > line = '\0' <repeats 504 times>, > "ï¿œï¿œï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000\006\003ï¿œï¿œï¿œ\000\000\000ï¿œ_ï¿œ\000\000ï¿œ&ï¿œ_ï¿œ", > '\0' <repeats 18 times>, > "ï¿œï¿œï¿œ_ï¿œ\000\000\020ï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000ï¿œ\005ï¿œ_ï¿œ\000\000ï¿œï¿œ~L\000\000\000\000=ï¿œ\002\000ï¿œ\000\000ï¿œ\000\000\000Ì¹ï¿œT\035ï¿œ_ï¿œï¿œdYhMï¿œ6T{ï¿œbjï¿œ\033\020v:ï¿œ*ï¿œb7\003a/ï¿œMï¿œï¿œï¿œï¿œï¿œï¿œ8ï¿œLï¿œï¿œXï¿œ\025Cï¿œÔ¶&Úxï¿œ6cï¿œOï¿œï¿œDpb*\030\tdï¿œï¿œï¿œ^biï¿œ}ï¿œï¿œ&ï¿œyï¿œfï¿œq"... > fp = (FILE *) 0x0 > rc = 0 > rc1 = 0 > i = 0 > first = 0 > ld = (LDAP *) 0x100401130 > seber = (BerElement *) 0x0 > vrber = (BerElement *) 0x0 > syncber = (BerElement *) 0x0 > syncbvalp = (struct berval *) 0x0 > err = 0 > > > Search was: > > /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 > -x -E > deref=member:mail "(CN=test)" mail > > Segmentation fault (core dumped) > > >

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> masarati(a)aero.polimi.it wrote: >>> quanah(a)zimbra.com wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: NA >>>> OS: NA >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.45.108) >>>> >>>> >>>> It would be extremely useful to have an extended operation that allows >>>> querying >>>> the number of children of a given (sub)tree, so that one can avoid >>>> iterating >>>> through the entire subtree to determine this number. >>>> >>> Might as well ask for the numSubordinates operational attribute to be >>> implemented instead, this doesn't seem to merit a new exop. And for >>> numSubordinates, see the -devel archives for why we chose not to >>> implement >>> it. >>> >>> In either case, the server still needs to iterate over all entries >>> internally, >>> and the result has to take ACLs and entry disclosure into account. >> >> An exop would allow to easily discriminate between intentional and >> "catchall" requests, like "+". Moreover, it might make sense to >> discriminate at least between subtree and onelevel number of >> subordinates; >> this would require two distinct operational attributes, or a parameter >> in >> the exop. >> >> I'm not endorsing either solution, I'm just pointing out possible pros >> and >> cons. > > If you want to be able to distinguish results based on scope then it makes > more sense to just define a Search control. Like No-op - count the entries > that would be returned, instead of returning them. (And bypassing the > sizelimit too, but probably not bypassing timelimit.) I'm drafting the code to implement this no-op search. The semantics consists in a control request in a search request that results in returning no intermediate responses, only a final response with a control response that contains summary information on what the search would have done. The request control value is empty. The response control value contains: - the error that the search would have returned if it were performed regularly (should differ from the one actually returned only in case of sizelimit exceeded) - the number of entries that would be returned - the number of search references that would be returned The search request should request no attributes (in any case no attributes will be returned); I'm not sure whether it is preferable to simply ignore requested attrs or the control must require that no attrs ("1.1") be explicitly requested; I favor the first (ignore req attrs) to ease interoperability; similarly, attrsOnly can be safely ignored. The rest of the search should be dealt with as usual (base, scope, filter, alias dereferencing and so on), as well as ACL. This allows, for example, to count immediate children (scope=onelevel), to count subtrees (scope=subtree); the filter allows to select what is counted; and so on. The code is almost done; am I missing anything? In case, let me know so I can fix it before committing. Thanks, p.

1 0

ITS#6636
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

The ITS is intended to track software bugs (see the charter for details). Software usage requests should be directed to openldap-technical(a)openldap.org (see the charter for details). This ITS will be closed. p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> Hello, > >> Hi. I don't have time to work at this right now, but I think the >> solution >> would be to modify slapo-chain(5) so that when a referral's DN is "" and >> the DN in the original request is not "", to use that DN instead. The >> original request DN can be found in op->o_req_dn. > > we tested the following - with success: > > Just replace in servers/slapd/back-ldap/chain.c, function > ldap_chain_op(), line 485-486: > > op->o_req_dn = pdn; > op->o_req_ndn = ndn; > > With: > > if (pdn.bv_len > 0) { > op->o_req_dn = pdn; > } > if (ndn.bv_len > 0) { > op->o_req_ndn = ndn; > } > > It would be great if this came into the official code. This issue was fixed consistently in HEAD code more than a month ago, please test it and report, so in case it works the ITS can be closed and the fix released. Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by jochen＠keutel.de 05 Sep '10

05 Sep '10

Hello, > Hi. I don't have time to work at this right now, but I think the solution > would be to modify slapo-chain(5) so that when a referral's DN is "" and > the DN in the original request is not "", to use that DN instead. The > original request DN can be found in op->o_req_dn. we tested the following - with success: Just replace in servers/slapd/back-ldap/chain.c, function ldap_chain_op(), line 485-486: op->o_req_dn = pdn; op->o_req_ndn = ndn; With: if (pdn.bv_len > 0) { op->o_req_dn = pdn; } if (ndn.bv_len > 0) { op->o_req_ndn = ndn; } It would be great if this came into the official code. Regards, Jochen.

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 04 Sep '10

04 Sep '10

--On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister <whm(a)stanford.edu> wrote: The problem with the database was only coincidental. Restoring the database got the failing replica past the problem replication event. In the replica pool of 6 servers we have seen the problem on there of the servers. In thinking about this more it is unlikely that it is a slave problem since the slaves have been in use for about 6 weeks and we did not see the problem. Only when we changed the master to 2.4.23 did we see the problem. I have captured a master debug log of the problem event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 03 Sep '10

03 Sep '10

Worked on this a bit more and in the end rebooted the server just to be sure I had a clean environment. When the system came back up slapd refused to start, the bdb database was corrupt. I reloaded from the master and replication is again working. Not sure why a reboot was required to uncover the error. I had stopped and started slapd multiple times without an errors being reported. Sorry for the inbox pollution. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 03 Sep '10

03 Sep '10

Full_Name: Bill MacAllister Version: 2.4.23-1 OS: Debian Lenny URL: http://www.stanford.edu/~whm/files/ldap-replication-error.txt Submission from: (NULL) (99.55.172.208) I just replaced a 2.3.43 OpenLDAP master with a 2.4.23-1 master. There are 6 slaves all running 2.4.23-1. After reloading the master database, I confirmed that replication was working my making some changes and then examining contextCSNs. Sometime later replication stopped on one of the servers. Looking at the log on the failing slave I saw: Sep 2 22:12:53 directory3 slapd[7005]: do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 2 22:12:53 directory3 slapd[7005]: do_syncrep2: rid=000 (-1) Can't contact LDAP server Sep 2 22:12:53 directory3 slapd[7005]: do_syncrepl: rid=000 rc -1 retrying On the master I saw: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 fd=38 ACCEPT from IP=171.67.218.156:44519 (IP=0.0.0.0:389) Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=0 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=1 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND authcid="ldap/directory3.stanford.edu(a)stanford.edu" authzid="ldap/directory3.stanford.edu(a)stanford.edu" Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND dn="cn=directory3,cn=ldap,cn=operational,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 RESULT tag=97 err=0 text= Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=3 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 fd=38 closed (connection lost on write) Running slapd on the failing slave with -d -1 I saw: =>do_syncrep2 rid=000 ldap_result ld 0x1c07000 msgid 4 wait4msg ld 0x1c07000 msgid 4 (timeout 0 usec) wait4msg continue ld 0x1c07000 msgid 4 all 0 ** ld 0x1c07000 Connections: * host: directory-master.stanford.edu port: 389 (default) refcnt: 2 status: Connected last used: Thu Sep 2 22:12:53 2010 ** ld 0x1c07000 Outstanding Requests: * msgid 4, origid 4, status InProgress outstanding referrals 0, parent count 0 ld 0x1c07000 request count 1 (abandoned 0) ** ld 0x1c07000 Response Queue: Empty ld 0x1c07000 response count 0 ldap_chkResponseList ld 0x1c07000 msgid 4 all 0 ldap_chkResponseList returns ld 0x1c07000 NULL ldap_int_select read1msg: ld 0x1c07000 msgid 4 all 0 ber_get_next sasl_generic_read: want=4, got=4 0000: 00 00 00 78 ...x sasl_generic_read: want=120, got=120 ... lots of output ... sasl_generic_read: want=45833, got=0 ldap_read: want=8, got=0 ber_get_next failed. ldap_err2string do_syncrep2: rid=000 (-1) Can't contact LDAP server I am including a pointer to the complete debug log. Looks like something in the sasl support is unhappy. We are using libsasl2-modules-gssapi-heimdal 2.1.23.dfsg1-5~sbp50+2. Strange to me that this one server is having a problem. There are actually 5 slaves that are working just fine. Here are current contextCSNs for the systems. directory-master contextCSN: 20100903060040.713677Z#000000#000#000000 directory1 contextCSN: 20100903060040.713677Z#000000#000#000000 directory2 contextCSN: 20100903060040.713677Z#000000#000#000000 directory3 contextCSN: 20100903015531.064407Z#000000#000#000000 directory4 contextCSN: 20100903060040.713677Z#000000#000#000000 directory11 contextCSN: 20100903060040.713677Z#000000#000#000000 directory12 contextCSN: 20100903060040.713677Z#000000#000#000000 What else should I look at? Bill

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