From owner-freebsd-ports@FreeBSD.ORG Tue Apr 11 19:48:49 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D0A16A405 for ; Tue, 11 Apr 2006 19:48:49 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DCC143D49 for ; Tue, 11 Apr 2006 19:48:48 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.1.108] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.4/8.13.4) with ESMTP id k3BJmj4h049382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Apr 2006 14:48:45 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <443C081D.6020408@palisadesys.com> Date: Tue, 11 Apr 2006 14:48:45 -0500 From: Guy Helmer User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: nss_ldap causes abort in sshd when local user logs in X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2006 19:48:49 -0000 I have nss_ldap 249 installed on FreeBSD 5.4 and 6.1 (prerelease) from FreeBSD's net/nss_ldap port. "passwd: files ldap winbind" & "group: files ldap winbind" are set in /etc/nsswitch.conf. However, nss_ldap causes an abort signal when I try to login to my local account (which exists in /etc/master.passwd) via ssh. Removing ldap from the group line in /etc/nsswitch.conf allows me to login but without my group memberships from LDAP (server is OpenLDAP 2.2.29). I've filed a bug report at padl.com in case this is truly a bug. Any advice? Please Cc: me on any replies. /usr/local/etc/ldap.conf contains: base dc=palisadesys,dc=com uri ldap://ldap.palisadesys.com/ pam_filter objectclass=posixAccount pam_login_attribute uid pam_member_attribute memberuid nss_base_passwd ou=People,dc=palisadesys,dc=com?one nss_base_group ou=Group,dc=palisadesys,dc=com?one pam_password MD5 I've rebuilt nss_ldap with --enable-debugging and DEBUG_SYSLOG set in config.h. Here are the results of a login where nss_ldap aborts: Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:567 thread 674514248 - ==> _nss_ldap_enter Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:590 thread 674514248 - <== _nss_ldap_enter Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:1857 thread 674514248 - ==> _nss_ldap_ent_context_release Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:1895 thread 674514248 - <== _nss_ldap_ent_context_release Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:599 thread 674514248 - ==> _nss_ldap_leave Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:617 thread 674514248 - <== _nss_ldap_leave Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:567 thread 674514248 - ==> _nss_ldap_enter Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:590 thread 674514248 - <== _nss_ldap_enter Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:3182 thread 674514248 - ==> _nss_ldap_getent_ex Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:1808 thread 674514248 - ==> _nss_ldap_ent_context_init_locked Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:1845 thread 674514248 - <== _nss_ldap_ent_context_init_locked Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:2969 thread 674514248 - ==> _nss_ldap_search Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:976 thread 674514248 - ==> do_init Apr 11 12:27:31 machine sshd[66677]: nss_ldap: __session.ls_state=-1, __session.ls_conn=0x0, __pid=66675, pid=66677, __euid=0, euid=0 Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:780 thread 674514248 - ==> do_close_no_unbind Apr 11 12:27:31 machine sshd[66677]: nss_ldap: ldap-nss.c:785 thread 674514248 - <== do_close_no_unbind (connection was not open) Backtrace of the sshd corefile gives this: #0 0x282c737b in kill () from /lib/libc.so.5 #1 0x282bc422 in raise () from /lib/libc.so.5 #2 0x2832ebc3 in abort () from /lib/libc.so.5 #3 0x283099a7 in __assert () from /lib/libc.so.5 #4 0x2836448b in do_init () at ldap-nss.c:1193 #5 0x2836656f in _nss_ldap_search (args=0x0, filterprot=0x28379400 "(&(objectclass=posixGroup))", sel=LM_GROUP, user_attrs=0x0, sizelimit=0, msgid=0xbfbfdfa8, csd=0x80735d4) at ldap-nss.c:2973 #6 0x28366a8e in _nss_ldap_getent_ex (args=0x0, ctx=0x28372c80, result=0x28345b5c, buffer=0x8084400 "nobody", buflen=1024, errnop=0xbfbfe0d0, filterprot=0x28379400 "(&(objectclass=posixGroup))", sel=LM_GROUP, user_attrs=0x0, parser=0x28368a3c <_nss_ldap_parse_gr>) at ldap-nss.c:3205 #7 0x283669c6 in _nss_ldap_getent (ctx=0x28372c80, result=0x28345b5c, buffer=0x8084400 "nobody", buflen=1024, errnop=0xbfbfe0d0, filterprot=0x28379400 "(&(objectclass=posixGroup))", sel=LM_GROUP, parser=0x28368a3c <_nss_ldap_parse_gr>) at ldap-nss.c:3160 #8 0x283696a7 in _nss_ldap_getgrent_r (result=0x28345b5c, buffer=0x8084400 "nobody", buflen=67044, errnop=0x5) at ldap-grp.c:1254 #9 0x282b2ed5 in __nss_compat_getgrent_r () from /lib/libc.so.5 #10 0x2830d7b1 in nsdispatch () from /lib/libc.so.5 #11 0x282ebfca in getgrent_r () from /lib/libc.so.5 #12 0x282ec25c in getgrgid_r () from /lib/libc.so.5 #13 0x282ec15a in getgrgid_r () from /lib/libc.so.5 #14 0x282ec2d5 in getgrent () from /lib/libc.so.5 #15 0x282c00f1 in getgrouplist () from /lib/libc.so.5 #16 0x282bdc9a in initgroups () from /lib/libc.so.5 #17 0x280cfb50 in setusercontext () from /lib/libutil.so.4 #18 0x08059d44 in cleanup_exit () In frame 4, the line in which the assert is triggered is: assert (cfg->ldc_uris[__session.ls_current_uri] != NULL); where __session.ls_current_uri is 0 and cfg->ldc_uris[__session.ls_current_uri] is 0x0. Guy -- Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc.