openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6979) test062 portability
by richton＠nbcs.rutgers.edu 23 Jun '11

23 Jun '11

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: Submission from: (NULL) (166.217.78.192) It looks like checking the function exit isn't portable; maybe some kind of bash-ism. It looks like the code was on the path to communicating the retval via $RCOUT file already? As such, here's one quick workaround, although I'd love something a bit more elegant: --- test062-config-delete~ 2011-06-23 07:21:01.387583000 -0400 +++ test062-config-delete 2011-06-23 07:21:14.884787000 -0400 @@ -106,7 +106,7 @@ ( $LDAPSEARCH -D cn=config -H $URI1 -y $CONFIGPWF -bcn=config -E \!sync=rp >/dev/null 2>&1 RC=$? - touch $RCOUT + echo $RC > $RCOUT exit $RC ) & @@ -137,7 +137,7 @@ if test -f "$RCOUT" ; then wait $SEARCHPID - SEARCHRC=$? + SEARCHRC=`cat $RCOUT` echo "Checking return code of backgrounded RefreshAndPersist search ..." if test $SEARCHRC != 52 ; then echo "Error: Backgrounded ldapsearch did return the wrong error code: $SEARCHRC"

1 0

(ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com 22 Jun '11

22 Jun '11

Full_Name: Jan Vcelak Version: 2.5.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfault… Submission from: (NULL) (209.132.186.34) Hello, input LDIF file with splitted lines which are indented incorrectly causes SEGFAULT of a client tool. Let me show: $ cat /tmp/invalid.ldif dn: cn=B,dc=my-domain, dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top cn: B sn: B uid: B mail: b(a)example.org $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048 ldif_parse_line: missing ':' after dc=com ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," Segmentation fault (core dumped) (gdb) bt full #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 No locals. #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, ctx=0x0) at ldifutil.c:399 fv = 0 line = 0x668627 "dc=com" dn = 0x668614 "cn=B,dc=my-domain," rc = -9 modop = 0 expect_modop = 0 expect_sep = 0 ldapadd = 1 new_entry = 1 delete_entry = 0 got_all = 0 pmods = 0x6697e8 version = 0 pctrls = 0x0 i = 1 j = 0 k = -1 idn = 1 nmods = 1 bvl = 0x6697f8 bv = {bv_len = 0, bv_val = 0x0} __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x" #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0, linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at ldifutil.c:565 No locals. #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at ldapmodify.c:404 lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614 "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename = {lr_newrdn = {bv_len = 0, bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0}, lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0}, lr_extop_data = { bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0, lr_lines = 2, lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals = 0x669930, lr_btype = 0x669880} lrflags = 1 rc = 0 rbuf_bv = {bv_len = 0, bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass: organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: B\nmail: b(a)example.org\n"} #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at ldapmodify.c:316 rbuf = 0x668610 "dn" rejbuf = 0x0 rejfp = 0x0 ldiffp = 0x6600a0 ldifdummy = {fp = 0x0, prev = 0x0} matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!" error_msg = 0x8000 <Address 0x8000 out of bounds> rc = 0 retval = 0 ldifrc = 1 len = 4491152 i = 0 lineno = 1 nextline = 11 lmax = 4119 c = {{ldctl_oid = 0x7fe0f05 <Address 0x7fe0f05 out of bounds>, ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0 '\000'}} (gdb) frame 1 #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, ctx=0x0) at ldifutil.c:399 399 if ( !BV_CASEMATCH( lr->lr_btype+i, &bv )) { (gdb) p *(lr->lr_btype+1) $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"} (gdb) bv_len is set incorrectly to zero and therefore the string will be compared against bv, which is a "null string". I have uploaded patch to address this issue. With the patch applied, the output is following: ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 ldif_parse_line: missing ':' after dc=com ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"

1 0

(ITS#6977) ldapwhoami minor verbose bugfix patch submission
by checker＠d6.com 21 Jun '11

21 Jun '11

Full_Name: Chris Hecker Version: 2.4.25 OS: centos 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.248.126.162) Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is not specified due to a minor bug in the code. Here is a fix. I am running 2.3.43, but just checked the latest repository version and the bug is still there (although at line 203 now), so I marked the version above as latest. Thanks, Chris --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11 17:24:07.000000000 -0600 +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 14:15:28.000000000 -0500 @@ -215,7 +215,7 @@ skip: if ( verbose || ( code != LDAP_SUCCESS ) || - matcheddn || text || refs || ctrls ) + (matcheddn && *matcheddn) || (text && *text) || refs || ctrls ) { printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code );

1 0

Re: (ITS#6976) Build OpenLDAP on Solaris : error : could not locate usable POSIX Threads
by Howard Chu 21 Jun '11

21 Jun '11

The ITS is for actual bugs in the software. This looks like a misconfiguration in your build environment, not an OpenLDAP bug. You should ask for help on the openldap-technical mailing list instead.

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by hyc＠symas.com 21 Jun '11

21 Jun '11

ctcard(a)hotmail.com wrote: >> Don't send HTML emails to the ITS.Apologies. >> >> I'm unable to reproduce the error you're talking about. Please provide a >> config that demonstrates the error, and the complete ldapsearch command >> invocation. > The original submission contained the ldapsearch command: > ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E > \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 I also asked for a server config that demonstrates the problem. When you omit key details, particularly when they are specificly requested, you only slow down the troubleshooting process. From your description in this email, I'm guessing that you've configured sssvlv as a global overlay instead of on a specific database. That's why the overlay is running before fe_op_search. I was testing with the overlay on a specific database. You should probably change your server configuration as a workaround until this gets patched. > (I just suppressed the bind dn, base dn and password) > The important aspect of the search command is that it is doing a server-sidesort on the mail attribute, is asking for a virtual list view, but is letting the size default to zero (which should mean unlimited). >> >> Your patch cannot be correct since limits_check() is already called by the >> frontend at the beginning of every search operation. > > Not in my experience. > As far as I can see limits_check() is called only in fe_op_search() in search.c, and when debugging I found that fe_op_search() was being called from overlay_op_walk() in backover.c. > > When the ldapsearch command is run, it sends a search request to slapd, which returns the first 11 records found, in order of the mail attribute. Then ldapsearch prompts > Press [before/after(/offset/count|:value)] Enter for the next window. > and on hitting enter ldapsearch sends the next request to slapd. This time the request gets handled by sssvlv_op_search() before fe_op_search() is called, because there is an active session. > int overlay_op_walk( Operation *op, SlapReply *rs, slap_operation_t which, slap_overinfo *oi, slap_overinst *on){ BI_op_bind **func; int rc = SLAP_CB_CONTINUE; > for (; on; on=on->on_next ) { func =&on->on_bi.bi_op_bind; if ( func[which] ) { op->o_bd->bd_info = (BackendInfo *)on; rc = func[which]( op, rs ); /*<--- sssvlv_op_search() called here */ if ( rc != SLAP_CB_CONTINUE ) break; } } if ( rc == SLAP_CB_BYPASS ) rc = SLAP_CB_CONTINUE; > func =&oi->oi_orig->bi_op_bind; if ( func[which]&& rc == SLAP_CB_CONTINUE ) { op->o_bd->bd_info = oi->oi_orig; rc = func[which]( op, rs ); /*<--- fe_op_search() called here */ } > Chris -- -- 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#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 21 Jun '11

21 Jun '11

> Don't send HTML emails to the ITS.Apologies. > > I'm unable to reproduce the error you're talking about. Please provide a > config that demonstrates the error, and the complete ldapsearch command > invocation. The original submission contained the ldapsearch command: ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 (I just suppressed the bind dn, base dn and password) The important aspect of the search command is that it is doing a server-sidesort on the mail attribute, is asking for a virtual list view, but is letting the size default to zero (which should mean unlimited). > > Your patch cannot be correct since limits_check() is already called by the > frontend at the beginning of every search operation. Not in my experience. As far as I can see limits_check() is called only in fe_op_search() in search.c, and when debugging I found that fe_op_search() was being called from overlay_op_walk() in backover.c. When the ldapsearch command is run, it sends a search request to slapd, which returns the first 11 records found, in order of the mail attribute. Then ldapsearch prompts Press [before/after(/offset/count|:value)] Enter for the next window. and on hitting enter ldapsearch sends the next request to slapd. This time the request gets handled by sssvlv_op_search() before fe_op_search() is called, because there is an active session. int overlay_op_walk( Operation *op, SlapReply *rs, slap_operation_t which, slap_overinfo *oi, slap_overinst *on){ BI_op_bind **func; int rc = SLAP_CB_CONTINUE; for (; on; on=on->on_next ) { func = &on->on_bi.bi_op_bind; if ( func[which] ) { op->o_bd->bd_info = (BackendInfo *)on; rc = func[which]( op, rs ); /* <--- sssvlv_op_search() called here */ if ( rc != SLAP_CB_CONTINUE ) break; } } if ( rc == SLAP_CB_BYPASS ) rc = SLAP_CB_CONTINUE; func = &oi->oi_orig->bi_op_bind; if ( func[which] && rc == SLAP_CB_CONTINUE ) { op->o_bd->bd_info = oi->oi_orig; rc = func[which]( op, rs ); /* <--- fe_op_search() called here */ } Chris

1 0

(ITS#6976) Build OpenLDAP on Solaris : error : could not locate usable POSIX Threads
by chathuraka.senaratne＠gmail.com 20 Jun '11

20 Jun '11

Full_Name: Samarasooriyage Gayan Chathuraka Senaratne Version: 3 OS: Solaris 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.69.193.78) When I try to configure OpenLDAP on Solaris I get the following error messages. I think I've set the library path environment variable to include the location of libpthread. configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: see the Autoconf documentation configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: pthread.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for pthread.h... yes checking POSIX thread version... 6 checking for LinuxThreads pthread.h... no checking for GNU Pth pthread.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for pthread_create in default libraries... no checking for pthread link with -kthread... no checking for pthread link with -pthread... no checking for pthread link with -pthreads... no checking for pthread link with -mthreads... no checking for pthread link with -thread... no checking for pthread link with -lpthread -lmach -lexc -lc_r... no checking for pthread link with -lpthread -lmach -lexc... no checking for pthread link with -lpthread -Wl,-woff,85... no checking for pthread link with -lpthread... no checking for pthread link with -lc_r... no checking for pthread link with -threads... no checking for pthread link with -lpthreads -lmach -lexc -lc_r... no checking for pthread link with -lpthreads -lmach -lexc... no checking for pthread link with -lpthreads -lexc... no checking for pthread link with -lpthreads... no configure: error: could not locate usable POSIX Threads Please help to solve this. Thanks Gayan

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by hyc＠symas.com 20 Jun '11

20 Jun '11

ctcard(a)hotmail.com wrote: > --_bbdbd3bd-a986-4f81-a676-3a9863fcc4f3_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable Don't send HTML emails to the ITS. I'm unable to reproduce the error you're talking about. Please provide a config that demonstrates the error, and the complete ldapsearch command invocation. Your patch cannot be correct since limits_check() is already called by the frontend at the beginning of every search operation. >> Date: Fri=2C 17 Jun 2011 09:33:22 -0700 >> From: quanah(a)zimbra.com >> To: ctcard(a)hotmail.com=3B openldap-its(a)openldap.org >> Subject: RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch >> =20 >> --On Friday=2C June 17=2C 2011 8:23 AM +0000 ctcard(a)hotmail.com wrote: >> =20 >>> >>> >>>> --On Thursday=2C June 16=2C 2011 5:14 PM +0000 ctcard(a)hotmail.com wrot= > e: >>>> >>>>> >>>>> openldap 2.4.25 is better=2C but still has the LDAP_SIZELIMIT_EXCEED= > ED >>>>> bug.A possible fix is to add a call to limits_check() >>>> >>>> >>>> Please read<http://www.openldap.org/devel/contributing.html> >>>> >>>> Particularly: >>>> >>>> <http://www.openldap.org/devel/contributing.html#patches> >>> Ok=2C patch uploaded to ftp.openldap.org >>> Chris =09 >> =20 >> And the FTP URL for the patch? >> =20 > I uploaded it to the incoming directory on ftp.openldap.org with the name (= > from memory) chris-card-110617.sssvlv.c.patch as per the instructions. > > Chris -- -- 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#6975) Patch - Mozilla NSS - should allow cacertdir in most cases
by rmeggins＠redhat.com 20 Jun '11

20 Jun '11

Full_Name: Rich Megginson Version: 2.4.25 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/Mozilla-NSS-should-allow-cacertdir-in-most-… Submission from: (NULL) (76.113.106.30) openldap built with openssl allows most any value of cacertdir - directory is a file, directory does not contain any CA certs, directory does not exist - users expect if they specify TLS_REQCERT=never, no matter what the TLS_CACERTDIR setting is, TLS/SSL will just work. On the other hand, TLS_CACERT failures are hard failures - if TLS_CACERT is specified and is not a valid file, TLS/SSL will fail. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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.

1 0

Re: (ITS#6734) Implment delta-sync based MMR
by hyc＠symas.com 20 Jun '11

20 Jun '11

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > To help resolve ITS#6097, it would be helpful to have delta-sync MMR available. > I'm mainly filing this bug for tracking. Experimental support is now in master. A test script is provided but it probably needs to be extended. -- -- 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