openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: objectClass index from slapd.conf is not working
by tim stone 06 Sep '10

06 Sep '10

Hello, the line "index objectClass eq" is the first index in my config and placed there before first filling the database. But I tried to rebuild this index with slapindex too and I also set up the hole database with slapcat/slapadd on a new testsystem. Every time the same behavior. kindly regards, Tim 2010/9/2 tim stone <timstone10001(a)googlemail.com> > > Hello Michael, > > the line > > "index objectClass eq" > > is the first index in my config and placed there before first filling the database. But I tried to rebuild this index with slapindex too and I also set up the hole database with slapcat/slapadd on a new testsystem. Every time the same behavior. > > kindly regards, Tim > > 2010/9/2 Michael Ströder <michael(a)stroeder.com> >> >> tim stone wrote: >> > >> > I've a strange behavior while using index objectClass for searching. >> >> Did you change the objectClass index *after* populating your database? >> >> http://www.openldap.org/faq/data/cache/136.html >> >> Ciao, Michael. >

2 1

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by michael＠stroeder.com 06 Sep '10

06 Sep '10

masarati(a)aero.polimi.it wrote: >> 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. Maybe sizelimit should not be by-passed in all cases. How about letting the client choose which limits are by-passed? Ciao, Michael.

1 0

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

05 Sep '10

Should now be fixed in HEAD; platform independent, on Linux was not failing but memory was being used incorrectly. ldapsearch-specific, no issue in client library. Please test. Thanks, p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by masarati＠aero.polimi.it 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. 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

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