openldap-bugs

openldap-bugs@openldap.org

1 participants
21026 discussions

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

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