- openldap-bugs - openldap.org

Re: (ITS#4922)
by ando＠sys-net.it 19 Apr '07

19 Apr '07

Juri Tanganelli wrote: > After further debugging i found the following behaviour: > > The entry has the uid attribute correctly initialized: uid S287384. Then it should have a corresponding normalized value "s287384" (note the lowercase "s") in the a_nvals array of bervals of the Attribute strycture where it's stored. If it doesn't (e.g. because the attribute was created incorrectly by your custom backend) then the behavior you see makes perfectly sense, and is not indicative of a software bug in OpenLDAP software. p. > If the uid starts with a capital letter then using these two filters: > > (uid=S287384) or (uid=s287384) doesn't return any result. > > If the uid attribute starts with a lower case letter ( i.e. uid=s287384 > ) then both filters work and return the entry. > The definition of the uid attribute is embodied in openldap source code > and from what i have seen it should be treated as a case insensitive > attribute. How to explain this behaviour?? 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#4932) Core dump caused in ldap_extended_operation()
by h.b.furuseth＠usit.uio.no 19 Apr '07

19 Apr '07

rguerrero(a)datamirror.com writes: > ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c" > ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c" > do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c" Looks like an ldap-nss.c problem to me, not an OpenLDAP problem. An uninitialized (or destroyed but not zeroed) LDAP*, perhaps? Look at the value of *session, in particular session->ls_conn, in the do_start_tls() frame. -- Regards, Hallvard

1 0

(ITS#4922)
by juritanganelli＠gmail.com 19 Apr '07

19 Apr '07

------=_Part_125517_21113365.1176969864256 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline After further debugging i found the following behaviour: The entry has the uid attribute correctly initialized: uid S287384. If the uid starts with a capital letter then using these two filters: (uid=S287384) or (uid=s287384) doesn't return any result. If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry. The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour?? Best Regards, Juri. ------=_Part_125517_21113365.1176969864256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div>After further debugging i found the following behaviour:</div> <div> </div> <div>The entry has the uid attribute correctly initialized: uid S287384.</div> <div> </div> <div>If the uid starts with a capital letter then using these two filters:</div> <div> </div> <div>(uid=S287384) or (uid=s287384) doesn't return any result.</div> <div> </div> <div>If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry.</div> <div>The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour??</div> <div> </div> <div>Best Regards,</div> <div>Juri.</div> ------=_Part_125517_21113365.1176969864256--

1 0

(ITS#4932) Core dump caused in ldap_extended_operation()
by rguerrero＠datamirror.com 18 Apr '07

18 Apr '07

Full_Name: Ron Guerrero Version: 2.3.27 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.201.167.139) We've got an application that indirectly calls OpenLDAP APIs. One function in particular is causing our process to core dump. The stack trace generated by dbx is as follows: 0xd0128470 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1) pthread_kill(??, ??) at 0xd0128470 _p_raise(??) at 0xd0127f08 raise.raise(??) at 0xd0315740 abort.abort() at 0xd0344cb0 __assert_c99(??, ??, ??, ??) at 0xd03aede0 ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c" ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c" do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" _nss_ldap_search_s(args = 0x2ff196c8, filterprot = "(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, user_attrs = (nil), sizelimit = 1, res = 0x2ff19658), line 3047 in "ldap-nss.c" _nss_ldap_getbyname(args = 0x2ff196c8, result = 0x20131698, buffer = "", buflen = 1024, errnop = 0x2ff22ff8, filterprot = "(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, parser = 0xf027b97c), line 3394 in "ldap-nss.c" ldap-pwd.pw_byuid(this = ??, uid = ??), line 55 in "irs-pwd.c" _nss_ldap_getpwuid(uid = 138056), line 181 in "aix_authmeth.c" _getpwuid_shadow_r(??, ??, ??, ??, ??) at 0xd03d0900 _posix_getpwuid_shadow_r(??, ??, ??, ??, ??, ??) at 0xd03d02cc sniq.getpwuid_r(??, ??, ??, ??, ??) at 0xd249170c snigun(??, ??, ??) at 0xd2491648 nigconcbs(??, ??, ??) at 0xd28cc858 osncon(0x0, 0x0, 0x1803, 0x201090ec, 0x20105bec, 0x20105be4, 0x20105b70, 0x20105c20) at 0xd28cce6c kpuadef(??, ??, ??, ??, ??, ??, ??, ??) at 0xd1d0d1b4 upiini(0x0, 0x0, 0x0, 0x0, 0x200eda80, 0x200edca0, 0x200edef4, 0x2010fe40) at 0xd20f24d4 upiah0(??, ??, ??, ??, ??, ??, ??) at 0xd20efce4 kpuatch(??, ??, ??, ??, ??, ??, ??) at 0xd1d378fc OCIServerAttach(??, ??, ??, ??, ??) at 0xd20fbfb0 As you can see application makes a call to an Oracle API. Has anyone seen this issue before? Notice in ldap_start_tls() the first parameter, the ldap handle, is non-null. However, in ldap_extended_operation(), the ldap handle is null. Looking at the code, ldap_start_tls() is calling ldap_extended_operation() with the same ldap handle that was passed to it. The latest source files for extended.c and tls.c have not changed since the 2.3.27 release.

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 18 Apr '07

18 Apr '07

This seems really to be an PPC specific kernel (or glibc) issue. I think I was able to create an isolated testcase to reproduce that problem outside of the OpenLDAP libraries. I'll now bug our kernel guys with it. But removing the assert(0) from request.c was still the right thing as Hallvard already mentioned in his first reply. -- Ralf

1 0

Re: (ITS#4931) To integrate Open LDAP with Jetspeed2
by quanah＠stanford.edu 18 Apr '07

18 Apr '07

--On Wednesday, April 18, 2007 1:57 PM +0000 vaibhav(a)omnimessaging.com wrote: > Full_Name: > Version: openldap-2.2.13-2 > OS: redhat linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.211.142.177) > > > How to use OPENLDAP with jetspeed2 ? > > please guide me. > Also please let me know how to check if ldap is working with jetspeed. > > I installed LDAP with BDB also can see all entires in LDAP -Browser. > Bis issue is how to use LDAP with Jetspeed2 for auth. Hello, The OpenLDAP ITS system is for reporting bugs, not for asking usage questions. If you have questions specific to the OpenLDAP software, please use the "openldap-software(a)openldap.org" mailing list. On a side note, you may need to contact RedHat for support if you run into issues with the openldap release you are using, as it is significantly out of date. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4931) To integrate Open LDAP with Jetspeed2
by vaibhav＠omnimessaging.com 18 Apr '07

18 Apr '07

Full_Name: Version: openldap-2.2.13-2 OS: redhat linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.211.142.177) How to use OPENLDAP with jetspeed2 ? please guide me. Also please let me know how to check if ldap is working with jetspeed. I installed LDAP with BDB also can see all entires in LDAP -Browser. Bis issue is how to use LDAP with Jetspeed2 for auth. regards VAibhav KAle

1 0

(ITS#4930) slaptest should be quiet on success
by jsafranek＠redhat.com 18 Apr '07

18 Apr '07

Full_Name: Jan Safranek Version: 2.3.35 OS: Linux (Fedora 6) URL: Submission from: (NULL) (62.40.79.66) The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded' to stderr. IMHO it should do not output anything, especially to stderr, if everything is all right. Here is a small patch, causing the slaptest to display the aforementioned message only if -v switch is used: Index: servers/slapd/slaptest.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v retrieving revision 1.9 diff -r1.9 slaptest.c 107c107,108 < fprintf( stderr, "config file testing succeeded\n"); --- > if (verbose) > fprintf( stderr, "config file testing succeeded\n");

1 0

(ITS#4929) Contriware Tool to create backsql metadata and tables
by takyin＠hotmail.com 17 Apr '07

17 Apr '07

Full_Name: Paul Version: 2..3.34 OS: FC6 URL: ftp://ftp.openldap.org/incoming/paul-070417.tar.gz Submission from: (NULL) (219.79.33.240) Dear Sir/Madam, I am interested to contribute my work on a tool that help backsql to work with MYSQL 5.0. It will create all tables, functions and metadata in sql command that can fit into MYSQL ver 5.0 ============================================= Some brief information about the tool ============================================= It is a php program with web interface, user can select which schema they want and create the resultant sql command. It should work with openldap 2.3.34 . Yours Paul

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by quanah＠stanford.edu 16 Apr '07

16 Apr '07

--On Monday, April 16, 2007 6:31 PM +0000 ryan(a)stat.Berkeley.EDU wrote: > On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >> > 3) if you can reproduce this issue with an unstripped set of OpenLDAP >> > libraries that would make the backtrace more useful. >> >> ...which I think you build with >> env ac_cv_prog_STRIP=":" ./configure ... > > I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still > prepared with "STRIP = -s" which then leads to "install -s". I found this: > > http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html > > I edited build/top.mk and removed the '-s' from STRIP and the configure > stage prepared Makefiles with "STRIP = ". You can always just run: make install STRIP="" or rather than hacking the makefiles. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.Berkeley.EDU 16 Apr '07

16 Apr '07

On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote: > hyc(a)symas.com writes: > > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > > libraries that would make the backtrace more useful. > > ...which I think you build with > env ac_cv_prog_STRIP=":" ./configure ... I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still prepared with "STRIP = -s" which then leads to "install -s". I found this: http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html I edited build/top.mk and removed the '-s' from STRIP and the configure stage prepared Makefiles with "STRIP = ". But the original issue has been resolved due to a local build issue. Thanks! Ryan

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.Berkeley.EDU 16 Apr '07

16 Apr '07

On Fri, Apr 13, 2007 at 02:10:19PM -0700, Howard Chu wrote: > >cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. > >When > >cups tries to authenticate it is dumping core. The backtrace seems to show > >that > >it is crashing within the OpenLDAP code. I'm using the PADL libraries, not > >the > >native Solaris libraries. > > A few things: > 1) This is most likely going to be an nss_ldap issue. > 2) please provide the output for "info shared" in gdb. > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > libraries that would make the backtrace more useful. Thanks for your feedback. Your second tip, running "info shared", showed that cups was linking against 2 different LDAP libraries, the one I intended and the one in /opt/SFW/. Once I fixed the build everything worked just fine. This issue can be closed. Ryan

1 0

Problème with SASL/DIGEST-MD5 authentication
by Abdelmjid HALLOUM 16 Apr '07

16 Apr '07

hi, i am a beginer with OpenLDAP, i installed it in my mchine ubuntu 6 but when i the problem is : root # ldapadd ............................) SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database anyhelp?

2 1

Re: (ITS#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by hyc＠symas.com 16 Apr '07

16 Apr '07

imtiazpk82(a)gmail.com wrote: > Full_Name: Imtiaz Khadim > Version: 3 > OS: Window server 2000 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.38.48.230) > > > Hi, > > I am using Sun Iplanet Directory Server 5.2 That's your first problem. Nothing in this report has anything to do with OpenLDAP Software. I suggest you contact Sun for assistance, or upgrade from the Sun server to a current OpenLDAP release. This ITS will be closed. > and LDAP Version 3.0 to fetch > records. The Problem currently i am facing is as follow > > I have made three conection to Iplanet Directory with same authentication level. > Each connection apply diferent filter and fetch records. > First rule fetch 15000 records. > and 2nd and third fetch 700 record each and this schedule is to be run on every > day. > First time it fetch records correctly but when on next day it ran again 2nd and > third filter run correctly but when first filter is applied the API > ldap_search_s() return error code 0x34. Why this happen? the other two are > working fine and these three connections are part of one application. Can any > one help me out please. > > reagrds > Imtiaz Khadim > > > . > -- -- 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#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by imtiazpk82＠gmail.com 16 Apr '07

16 Apr '07

Full_Name: Imtiaz Khadim Version: 3 OS: Window server 2000 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.38.48.230) Hi, I am using Sun Iplanet Directory Server 5.2 and LDAP Version 3.0 to fetch records. The Problem currently i am facing is as follow I have made three conection to Iplanet Directory with same authentication level. Each connection apply diferent filter and fetch records. First rule fetch 15000 records. and 2nd and third fetch 700 record each and this schedule is to be run on every day. First time it fetch records correctly but when on next day it ran again 2nd and third filter run correctly but when first filter is applied the API ldap_search_s() return error code 0x34. Why this happen? the other two are working fine and these three connections are part of one application. Can any one help me out please. reagrds Imtiaz Khadim

1 0

Re: (ITS#4922) test_filter problem on uid filter
by ando＠sys-net.it 16 Apr '07

16 Apr '07

Please post replies to the ITS system. Juri Tanganelli wrote: > The entry e497004 is a candidate for sure My point is: it's clear that if you filter for (uid=e497004) the corresponding entry must be selected as candidate. But does it actually get selected, and does test_filter() get applied to it? I understand it's obvious, but the typical bug with things that have always worked is that one believes they don't work while the point is that they don't get used as one expects. You should check this. > : a filter on a different > attribute > of the same entry returns the correct result. I can provide you with any > information you need for an analysis of the problem (stack trace, variable > dumps, etc...). > What kind of information do you want me to produce? Well, you should check that when searching for (uid=e497004) test_filter() gets invoked and the entry passed to it contains the attribute "uid" with the value "e497004". To do this, you should run slapd within a debugger, set a breakpoint at test_filter() and, as soon as the function is entered, check the contents of e->e_attrs down the list until you find the "uid" attribute. If the attribute is there with the requested value, and it is searchable (ACL), test_filter() must succeed (return LDAP_COMPARE_TRUE). So you need to check: - the presence of "uid" - the presence of the desired value - the access privileges of the identity that runs the request It might be that test_filter() returns LDAP_COMPARE_TRUE but the result is handled incorrectly by your custom backend, or by the frontend based on the way the result is passed back to it. By stepping through the whole operation you should be able to detect what goes wrong. If you find out that the error is in test_filter(), we'll be happy of fixing it, of course. 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#4927) pam_authenticate through ldap causes cups to crash
by hyc＠symas.com 13 Apr '07

13 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> 3) if you can reproduce this issue with an unstripped set of OpenLDAP >> libraries that would make the backtrace more useful. > > ...which I think you build with > env ac_cv_prog_STRIP=":" ./configure ... > No need to rerun configure. Just "make install STRIP=" -- -- 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#4927) pam_authenticate through ldap causes cups to crash
by h.b.furuseth＠usit.uio.no 13 Apr '07

13 Apr '07

hyc(a)symas.com writes: > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > libraries that would make the backtrace more useful. ...which I think you build with env ac_cv_prog_STRIP=":" ./configure ... -- Regards, Hallvard

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by hyc＠symas.com 13 Apr '07

13 Apr '07

ryan(a)stat.berkeley.edu wrote: > Full_Name: Ryan Lovett > Version: 2.3.32 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.32.135.6) > > > cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. When > cups tries to authenticate it is dumping core. The backtrace seems to show that > it is crashing within the OpenLDAP code. I'm using the PADL libraries, not the > native Solaris libraries. A few things: 1) This is most likely going to be an nss_ldap issue. 2) please provide the output for "info shared" in gdb. 3) if you can reproduce this issue with an unstripped set of OpenLDAP libraries that would make the backtrace more useful. -- -- 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#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.berkeley.edu 13 Apr '07

13 Apr '07

Full_Name: Ryan Lovett Version: 2.3.32 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.32.135.6) cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. When cups tries to authenticate it is dumping core. The backtrace seems to show that it is crashing within the OpenLDAP code. I'm using the PADL libraries, not the native Solaris libraries. #0 0xfe50ddf0 in ldap_abandoned () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 (gdb) bt #0 0xfe50ddf0 in ldap_abandoned () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #1 0xfe50b354 in chkResponseList () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #2 0xfe50b230 in ldap_result () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #3 0xfe5d40f0 in do_bind (ld=0x1272d8, timelimit=30, dn=0xfe5f4a65 "uid=ldapadmin,cn=users,dc=our,dc=ldap,dc=domain", pw=0xfe5f4b7c "PaSsWoRD", with_sasl=1) at ldap-nss.c:1792 #4 0xfe5d49b8 in do_with_reconnect ( base=0xfe5f4acc "cn=users,dc=our,dc=ldap,dc=domain", scope=1, filter=0xffbefa60 "(&(objectClass=shadowAccount)(uid=op))", attrs=0xfe5f57dc, sizelimit=1, private=0xffbf02e0, search_func=0xfe5d4ef0 <do_search_s>) at ldap-nss.c:1620 #5 0xfe5d7a00 in _nss_ldap_search_s (args=0xffbf0368, filterprot=0xfe5fa2a0 "(&(objectClass=shadowAccount)(uid=%s))", sel=LM_SHADOW, user_attrs=0x0, sizelimit=1, res=0xffbf02e0) at ldap-nss.c:3047 #6 0xfe5d7b84 in _nss_ldap_getbyname (args=0xffbf0368, result=0x128430, buffer=0x12c0e0 "nobody4", buflen=1024, errnop=0xffbf0484, filterprot=0xfe5fa2a0 "(&(objectClass=shadowAccount)(uid=%s))", sel=LM_SHADOW, parser=0xfe5db86c <_nss_ldap_parse_sp>) at ldap-nss.c:3394 #7 0xfe5dbb88 in _nss_ldap_getspnam_r (be=0x3, args=0xffbf0460) at ldap-spwd.c:136 #8 0xfeddbbfc in nss_search () from /lib/libc.so.1 #9 0xfedcad80 in getspnam_r () from /lib/libc.so.1 #10 0xfeba9630 in nss_getpwnam () from /usr/lib/passwdutil.so.1 #11 0xfeba9778 in nss_getattr () from /usr/lib/passwdutil.so.1 #12 0xfeba2e90 in __get_authtoken_attr () from /usr/lib/passwdutil.so.1 #13 0xfebd0cf0 in pam_sm_authenticate () from /usr/lib/security/pam_authtok_get.so.1 #14 0xff2d2c88 in run_stack () from /lib/libpam.so.1 #15 0xff2d2f2c in pam_authenticate () from /lib/libpam.so.1 #16 0x00018b70 in cupsdAuthorize (con=0x140fe8) at auth.c:513 #17 0x0001eb98 in cupsdReadClient (con=0x140fe8) at client.c:1033 #18 0x0002dd04 in main (argc=476808, argv=0x461fc665) at main.c:934

1 0

Re: (ITS#4926) german special characters ( Umlaute ) in Password
by h.b.furuseth＠usit.uio.no 13 Apr '07

13 Apr '07

2.1.22 is very old. See if it helps to upgrade. OpenLDAP has had bugs with 8-bit characters, though admittedly I don't see how those would affect passwords. Have you checked that the bug is not in your C program's input routine? Print out the password before passing it to OpenLDAP. -- Regards, Hallvard

1 0

(ITS#4926) german special characters ( Umlaute ) in Password
by m.birkenkamp＠e-fact-gmbh.de 13 Apr '07

13 Apr '07

Full_Name: Marcel Birkenkamp Version: 2.1.22 OS: HP-UX 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.63.14.237) hi, i have a problem submitting passwords containing german special characters (Umlaute ä,ü,ö & ß) by using the OpenLDAP Function ldap_simple_bind_s to our Active Directory Server. After investigating the issue it seems as if the password is cut off at the position of the special char, since it is possible to log in a user with his password (without special characters) if i use the correct password and add one of these characters to the end. Example: password for user: test submitted: testö this would succeed the problem is if a user i.e. enters the password: bäume the submitted password is: b Is there a fix/workaround for this? btw: i'm using this in a c program. Thanks in advance.

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 13 Apr '07

13 Apr '07

On Friday 13 April 2007 01:11, Pierangelo Masarati wrote: > You should print the contents of "res", which contains the offending > response message type. (gdb) frame 3 #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 465 assert( 0 ); (gdb) print *res $5 = {lm_msgid = 530, lm_msgtype = 96, lm_ber = 0x10020238, lm_chain = 0x0, lm_chain_tail = 0x10021458, lm_next = 0x0, lm_time = 0} (gdb) print *res->lm_ber $6 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 96, ber_len = 13, ber_usertag = 0, ber_buf = 0x10021368 "\002\002\002\022`\a\002\001\003\004", ber_ptr = 0x1002136c "`\a\002\001\003\004", ber_end = 0x10021375 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 13 Apr '07

13 Apr '07

rhafer(a)suse.de wrote: > #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 > tv = {tv_sec = 0, tv_usec = 100000} > res = (LDAPMessage *) 0x10021458 > msgid = 530 > rc = 0 > passwd = {bv_len = 0, bv_val = 0x0} > err = 1 > savedefconn = (LDAPConn *) 0x10016098 > lc = (LDAPConn *) 0x10016310 > srv = (LDAPURLDesc *) 0x10020278 > __PRETTY_FUNCTION__ = "ldap_new_connection" You should print the contents of "res", which contains the offending response message type. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

Hallvard suggested that a backtrace might help. This is what I was able to get: (gdb) bt full #0 0x0fb4fce0 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x0fb51620 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x0fb478dc in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 tv = {tv_sec = 0, tv_usec = 100000} res = (LDAPMessage *) 0x10021458 msgid = 530 rc = 0 passwd = {bv_len = 0, bv_val = 0x0} err = 1 savedefconn = (LDAPConn *) 0x10016098 lc = (LDAPConn *) 0x10016310 srv = (LDAPURLDesc *) 0x10020278 __PRETTY_FUNCTION__ = "ldap_new_connection" #4 0x0ffb3c44 in ldap_send_server_request (ld=0x10016128, ber=0x10020338, msgid=529, parentreq=0x100163e0, srvlist=0x10020278, lc=0x0, bind=0xff9b4624) at request.c:206 lr = (LDAPRequest *) 0xffb6cb8 incparent = 1 rc = -6601376 #5 0x0ffb5d34 in ldap_chase_v3referrals (ld=0x10016128, lr=0x100163e0, refs=0x0, sref=1, errstrp=0x100163fc, hadrefp=0xff9b46f4) at request.c:1013 unfollowed = 0x0 unfollowedcnt = 0 origreq = (LDAPRequest *) 0x100163e0 srv = (LDAPURLDesc *) 0x10020278 ber = (BerElement *) 0x10020338 refarray = (char **) 0x10016218 lc = (LDAPConn *) 0x0 rc = 0 count = 0 i = 0 j = 267910176 id = 529 rinfo = {ri_msgid = 528, ri_request = 99, ri_url = 0x100201f0 "ldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub"} #6 0x0ff970e0 in try_read1msg (ld=0x10016128, msgid=528, all=1, lcp=0xff9b47e0, result=0xff9b48bc) at result.c:560 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 0, ber_len = 73, ber_usertag = 0, ber_buf = 0x100201a0 "\002\002\002\020sC\004Aldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub", ber_ptr = 0x100201e9 "", ber_end = 0x100201e9 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} refs = (char **) 0x10016218 ber = (BerElement *) 0x10020170 newmsg = (LDAPMessage *) 0x100162f0 l = (LDAPMessage *) 0x0 prev = (LDAPMessage *) 0x0 id = 528 tag = 115 len = 67 foundit = 0 lr = (LDAPRequest *) 0x100163e0 tmplr = (LDAPRequest *) 0x0 lc = (LDAPConn *) 0x10016098 tmpber = {ber_opts = {lbo_valid = 4095, lbo_options = 26992, lbo_debug = -6601008}, ber_tag = 4288366336, ber_len = 268140648, ber_usertag = 0, ber_buf = 0xffffffff <Address 0xffffffff out of bounds>, ber_ptr = 0x100170b8 "", ber_end = 0x3 <Address 0x3 out of bounds>, ber_sos = 0x10016128, ber_rwptr = 0x10016238 "", ber_memctx = 0xff9b4730} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 lderr = 268396596 tmp = (LDAPMessage *) 0x0 chain_head = (LDAPMessage *) 0x0 moremsgs = 0 isv2 = 0 v3ref = V3REF_TOAPP __PRETTY_FUNCTION__ = "try_read1msg" #7 0x0ff96994 in wait4msg (ld=0x10016128, msgid=528, all=1, timeout=0x0, result=0xff9b48bc) at result.c:344 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} tvp = (struct timeval *) 0x0 start_time = 0 tmp_time = -6600704 lc = (LDAPConn *) 0x10016098 __PRETTY_FUNCTION__ = "wait4msg" #8 0x0ff9612c in ldap_result (ld=0x10016128, msgid=528, all=1, timeout=0x0, result=0xff9b48bc) at result.c:124 lm = (LDAPMessage *) 0x0 rc = 268567256 __PRETTY_FUNCTION__ = "ldap_result" #9 0x0ff9a860 in ldap_search_s (ld=0x10016128, base=0x10016048 "o=Example,c=US", scope=2, filter=0x10016060 "cn=Barbara Jensen", attrs=0xff9b48ac, attrsonly=0, res=0xff9b48bc) at search.c:379 msgid = 528 #10 0x100020a0 in do_search (uri=0x0, host=0x10016008 "localhost", port=9013, manager=0x10016018 "cn=Manager,o=Example,c=US", passwd=0x10016038 "secret", sbase=0x10016048 "o=Example,c=US", filter=0x10016060 "cn=Barbara Jensen", maxloop=500, maxretries=20, delay=0) at slapd-search.c:201 ld = (LDAP *) 0x10016128 i = 263 do_retry = 20 attrs = {0x10003dfc "%d).\n", 0x10003e00 "\n", 0x0} pid = 13557 rc = 0 #11 0x10001eac in do_search (uri=0x0, host=0x0, port=19, manager=0xff9b4bd4 "�\233N��\233O\b�\233O\v�\233O\025�\233O\030�\233O\035�\233O �\233O:�\233O=�\233OD�\233OG�\233OJ�\233OM�\233OP�\233OS�\233OU�\233OX�\233Og�\233Oj", passwd=0x22 <Address 0x22 out of bounds>, sbase=0xff9b4bd4 "�\233N��\233O\b�\233O\v�\233O\025�\233O\030�\233O\035�\233O �\233O:�\233O=�\233OD�\233OG�\233OJ�\233OM�\233OP�\233OS�\233OU�\233OX�\233Og�\233Oj", filter=0xff9b4950 "�\233K\200\017�\217`�", maxloop=-134155200, maxretries=-134154560, delay=-134154568) at slapd-search.c:156 ld = (LDAP *) 0x10016038 i = 268525640 do_retry = 268525664 attrs = {0x10016018 "cn=Manager,o=Example,c=US", 0x10016008 "localhost", 0x0} pid = 0 rc = 20 #12 0x0fb38f60 in generic_start_main () from /lib/libc.so.6 No symbol table info available. #13 0x0fb3918c in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #14 0x00000000 in ?? () No symbol table info available. -- Ralf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs