openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6392)
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

This is a multi-part message in MIME format. --------------040503050400050604020005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Okay, so apparently it was a little easier to code than I anticipated. The supplied patch removes the error message I was seeing. Whether or not authid-rewrite actually works is a different question which I have yet to figure out. The second patch (for config.c) isn't directly related to this bug, but would be nice. I've never done a patch before, so I have no idea if I created these correctly. I used the command: diff -c oldfile newfile > file.diff Is this the proper way to do that? --------------040503050400050604020005 Content-Type: text/x-patch; name="config.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config.c.diff" *** config.c 2009-01-21 17:00:58.000000000 -0700 --- config.c.new 2009-11-21 00:56:08.000000000 -0700 *************** *** 288,294 **** } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, "" ); return -1; } --- 288,294 ---- } else { Debug( LDAP_DEBUG_ANY, "[%s:%d] unknown command '%s'\n", ! fname, lineno, argv[0] ); return -1; } --------------040503050400050604020005 Content-Type: text/x-patch; name="saslauthz.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="saslauthz.c.diff" *** saslauthz.c 2009-01-21 17:01:03.000000000 -0700 --- saslauthz.c.new 2009-11-21 00:52:15.000000000 -0700 *************** *** 1284,1289 **** --- 1284,1290 ---- ) { int rc; + int i; char *savearg0; /* init at first call */ *************** *** 1291,1300 **** sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } - /* strip "authid-" prefix for parsing */ savearg0 = argv[0]; argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); argv[0] = savearg0; return rc; --- 1292,1310 ---- sasl_rwinfo = rewrite_info_init( REWRITE_MODE_USE_DEFAULT ); } savearg0 = argv[0]; + /* temporarily shift argv to get rid of argv[0] */ + for ( i = 1; i <= argc; i++ ) { + argv[i-1] = argv[i]; + } + argc--; + /* strip "authid-" prefix for parsing */ argv[0] += STRLENOF( "authid-" ); rc = rewrite_parse( sasl_rwinfo, fname, lineno, argc, argv ); + argc++; + for ( i = argc; i >= 1; i-- ) { + argv[i] = argv[i-1]; + } argv[0] = savearg0; return rc; --------------040503050400050604020005--

1 0

(ITS#6392)
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

I tracked down the bug by going through the source code. Basically, slap_sasl_rewrite_config() in servers/slapd/saslauthz.c passes the information to rewrite_parse() in libraries/librewrite/config.c. However, what slap_sasl_rewrite_config() sends is NOT what rewrite_parse() expects to get. It looks like rewrite_parse is a generic function which is called all over the place. Probably not best to mess with that. However, slap_sasl_rewrite_config() is only called from servers/slapd/bconfig.c, so any changes could take place in either of those two places relatively easily. Anyway, what slap_sasl_rewrite_config has in my little test: fname = "slapd" lineno = 0 argc = 3 argv[0] = "olcAuthIDRewrite" argv[1] = "authid-rewriteEngine" argv[2] = "on" In rewrite_parse(), it expects it to be set up more like this: fname = "slapd" lineno = 0 argc = 2 argv[0] = "rewriteEngine" argv[1] = "on" So all that needs to happen in slap_sasl_rewrite_config() is: argc--; and Get rid of argv[0] and shift everything down in the array (1 ==> 0, 2 ==> 1, etc.) (?and then put it all back when finished?) Anyway, I'm not sure how to do that, so the most I can really help out here is by filing this report so you don't have to spend your time tracking down the issue. Second note: it would have helped with debugging had a particular debug command been properly finished. See libraries/librewrite/config.c, line 289-291. The debug command has the %s placeholder for the third argument, but is passed "" instead of something more useful like: argv[0]. Probably just a little oversight. Any way I can help with any of this?

1 0

(ITS#6392) olcAuthIDRewrite handler exited with 1
by wgillespie＠es2eng.com 21 Nov '09

21 Nov '09

Full_Name: Willie Gillespie Version: 2.4.X (from CVS) OS: Ubuntu 9.10 x64 URL: Submission from: (NULL) (208.47.173.116) Modify the attribute olcAuthIDRewrite in cn=config and you get: conn=0 op=7 RESULT tag=103 err=80 text=<olcAuthIDRewrite> handler exited with 1 It seems to do this with 2.4.18 and 2.4.19 as well as the version I downloaded from the CVS tonight (2009-11-20). If others don't seem to have the same problem, I'd be happy to list more information about my setup. This is my first ITS bug, so if you need more info about something, let me know and I can provide.

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 21 Nov '09

21 Nov '09

--On Friday, November 20, 2009 11:29 PM +0000 michael(a)stroeder.com wrote: > I think this is the right issue since Howard wrote to me: >> Your source seems to be corrupt or out of date. There is no call to >> memrchr anywhere near line 2889 in syncrepl.c This has been fixed in RE24, please try now. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 21 Nov '09

21 Nov '09

quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > >> --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: >> >>> Hm, I get the following warning during the make run: >>> >>> =2E./../../servers/slapd/syncrepl.c:2861 is: >>> comma =3D ber_bvrchr( &ptr, ',' ); >>> with ber_bvrchr being a macro around memrchr(). So it seems that >>> memrchr() = is=20 >>> undefined in syncrepl.c. >> >> Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I think this is the right issue since Howard wrote to me: > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c Ciao, Michael.

1 0

(ITS#6391) missing check for broken filters
by h.b.furuseth＠usit.uio.no 20 Nov '09

20 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl.c and overlays/pcache.c call str2filter() and str2filter_x() without checking for success. (so does retcode, but that overlay is only for testing anyway.)

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > >> Hm, I get the following warning during the make run: >> >> =2E./../../servers/slapd/syncrepl.c:2861 is: >> comma =3D ber_bvrchr( &ptr, ',' ); >> with ber_bvrchr being a macro around memrchr(). So it seems that >> memrchr() = is=20 >> undefined in syncrepl.c. > > > Please don't add secondary issues to an ITS. File a new one. Unless you're saying that is the issue, which isn't clear to me in what you wrote. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by quanah＠zimbra.com 20 Nov '09

20 Nov '09

--On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > Hm, I get the following warning during the make run: > > =2E./../../servers/slapd/syncrepl.c:2861 is: > comma =3D ber_bvrchr( &ptr, ',' ); > with ber_bvrchr being a macro around memrchr(). So it seems that > memrchr() = is=20 > undefined in syncrepl.c. Please don't add secondary issues to an ITS. File a new one. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 20 Nov '09

20 Nov '09

Am Freitag 20 November 2009 13:34:50 schrieb Ralf Haferkamp: [..] > ../../../servers/slapd/syncrepl.c:2861 is: > comma = ber_bvrchr( &ptr, ',' ); > with ber_bvrchr being a macro around memrchr(). So it seems that memrchr() > is undefined in syncrepl.c. This got introduced by the ITS#6351 fix. I wonder if we should just revert that. The alternative is to add a #define _GNU_SOURCE 1 to ac/string.h if HAVE_MEMRCHR is defined. -- Ralf

1 0

Re: (ITS#6390) test020 seg faults
by michael＠stroeder.com 20 Nov '09

20 Nov '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: RE24 >> OS: openSUSE Linux 11.2 (x86_64) >> URL: >> Submission from: (NULL) (84.163.84.65) >> >> >> Relevant build options: >> CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" > > The SLAP_LIGHTWEIGHT_DISPATCHER symbol no longer exists in RE24; it was made > the default long ago. > > Why are you testing a release candidate with -DDEVEL? You have no business > defining this, not for release testing. That's for private test builds and > *un*released features; i.e. things we are specifically excluding from > consideration in the release process. I've now set export CFLAGS="-g -O2" now and it still seg faults (after 26 runs). > Your source seems to be corrupt or out of date. There is no call to memrchr > anywhere near line 2889 in syncrepl.c ??? Right before the build I'm always doing cvs up -Rd . This shows me two merges in contrib/ code where I'd tweaked the Makefile to reflect the path of the working dir. Please advice what I should do better. Ciao, Michael.

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