openldap-bugs April 2007

openldap-bugs@openldap.org

38 participants
126 discussions

(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 12 Apr '07

12 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

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

12 Apr '07

Ralf Haferkamp wrote: > It's not back-ldap that's trying to chase referrals here. It's slapd-search > (from the tester binaries), but if I see it corretcly that has referral > chasing turned of as well. At least it is not started with the -C option, > which should enable referral chasing. That's indeed puzzling. OK, I completely screwed the thing. slapd-search doesn't do anything about referrals, so it sticks with the default of libldap (on); also, it seems to have no -C flag. I'll fix this in a moment. This leaves the open point of ldap_result() returning what appears to be LDAP_REQ_BIND instead of a LDAP_RES_* in response to ... LDAP_REQ_BIND itself. Still digging... 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

On Thursday 12 April 2007 17:39, Pierangelo Masarati wrote: > Ralf Haferkamp wrote: > > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was > >> already present in earlier versions? > > > > I checked back to 2.3.27 and the problem as present there as well. I was > > however not yet able to reproduce the issue on another architecture, I've > > been running test039 for a few hours on an Intel x86_64 box without any > > problem. > > So this problem might as well be locate in some other part of the system > > (kernel, glibc, ...). What do you think? > > What puzzles me is that referral chasing should be disabled in that > test. In fact, slapd.3.conf contains "chase-referrals no" for both > instances of back-ldap. It's not back-ldap that's trying to chase referrals here. It's slapd-search (from the tester binaries), but if I see it corretcly that has referral chasing turned of as well. At least it is not started with the -C option, which should enable referral chasing. That's indeed puzzling. -- Ralf

1 0

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

12 Apr '07

Ralf Haferkamp wrote: > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was >> already present in earlier versions? > I checked back to 2.3.27 and the problem as present there as well. I was > however not yet able to reproduce the issue on another architecture, I've > been running test039 for a few hours on an Intel x86_64 box without any > problem. > So this problem might as well be locate in some other part of the system > (kernel, glibc, ...). What do you think? > What puzzles me is that referral chasing should be disabled in that test. In fact, slapd.3.conf contains "chase-referrals no" for both instances of back-ldap. 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

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > Another comment: would it be possible to check if the problem was > already present in earlier versions? I checked back to 2.3.27 and the problem as present there as well. I was however not yet able to reproduce the issue on another architecture, I've been running test039 for a few hours on an Intel x86_64 box without any problem. So this problem might as well be locate in some other part of the system (kernel, glibc, ...). What do you think? -- Ralf

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2007