Bug#302296: libnss-ldap 238-1 causes "login: pthread_mutex_lock.c:78" error
Michael Berg
Version: 238-1
Severity: important
After upgrading libnss-ldap from 220-1 to 238-1, users were unable to log in via gdm anymore. Attempting to log in as root (which is in /etc/passwd) produces the following:
debian login: root
Password:
login: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Normal users (which are all stored in ldap) are able to log on the console without any problems. It was then possible to "su" to root from a normal user.
Downgrading to libnss-ldap 220-1 allowed root to log in on the console and users to log in via gdm.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.6-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libnss-ldap depends on:
ii debconf 1.4.47 Debian configuration management sy
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libkrb53 1.3.6-1 MIT Kerberos runtime libraries
ii libldap2 2.1.30-3 OpenLDAP libraries
-- debconf information:
* libnss-ldap/dblogin: false
libnss-ldap/override: true
* libnss-ldap/confperm: false
* shared/ldapns/ldap_version: 3
* libnss-ldap/nsswitch:
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stephen Frost
> After upgrading libnss-ldap from 220-1 to 238-1, users were
> unable to log in via gdm anymore. Attempting to log in as
> root (which is in /etc/passwd) produces the following:
>
> debian login: root
> Password:
> login: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
>
> Normal users (which are all stored in ldap) are able to log on
> the console without any problems. It was then possible to "su"
> to root from a normal user.
>
> Downgrading to libnss-ldap 220-1 allowed root to log in on the
> console and users to log in via gdm.
Forwarding this to the upstream mailing list (Cc'd). Are you using
libpam-ldap too? Does gdm log anything interesting about why it's
failing, or is it failing when logging in as root? Basically, are you
sure the gdm issue is the same as the root login on console issue?
What does your /etc/nsswitch.conf look like? What about your
/etc/libnss-ldap.conf? What specific version of glibc, what kernel are
you using, do you know if NPTL is enabled or not?
Luke & co., any thoughts on what this could be?
Thanks,
Stephen
Berg, Michael
Yes, I'm using libpam-ldap too. Both packages were upgraded at the same
time. I tried all four combinations of previous and new versions of both
packages. The problems occurred in both cases where the new libnss-ldap
was installed and didn't occur in either case with the old libnss-ldap
installed.
> Does gdm log anything interesting about why it's
> failing, or is it failing when logging in as root?
When the new libnss-ldap is installed, gdm fails (regardless of who is
attempting to log in). There does not appear to be anything interesting in
the gdm logs. The logs when users can't log in are identical to when users
could previously log in. I haven't tried running gdm through a debugger
yet, but I think gdm might be crashing as it momentarily dumps me back to a
console and then the gdm login screen restarts.
Similarly, there are not entries in /var/log/auth.log or /var/log/syslog
when root tried to log in on the console.
> Basically, are you sure the gdm issue is the same as the root login on console issue?
I'm not absolutely sure, but both problems start when I install the new
libnss-ldap and both problems go away when I revert to the old version.
It is possible that there are different bugs in both login and gdm, but if
that is the case, the new libnss-ldap is at least a common trigger.
> What does your /etc/nsswitch.conf look like?
--------------------
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns dns6
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
--------------------
> What about your /etc/libnss-ldap.conf?
I've stripped all comment lines to conserve space and sanitized internal
"ou" strings to "example.com"
--------------------
host ldap.example.com
base dc=example,dc=com
ldap_version 3
pam_password clear
nss_base_passwd ou=Users,dc=example,dc=com?one
nss_base_shadow ou=Users,dc=example,dc=com?one
nss_base_group ou=Groups,dc=example,dc=com?one
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/ssl/certs/example.com_CA.pem
tls_ciphers HIGH:!ADH
--------------------
> What specific version of glibc, what kernel are
> you using, do you know if NPTL is enabled or not?
glibc = libc6 and libc6-i686 from debian unstable (both at version
2.3.2.ds1-20). For the benefit of anyone at PADL not familiar with debian,
the libc6-i686 package redirects linking to i686 optimized versions of the
C libraries while utilizing all the manual pages, timezone info, and other
common files from the libc6 package.
kernel = 2.6.11.6 from kernel.org, compiled for an AMD-XP (K7)
NPTL is enabled (on by default with a 586 or higher optimized libc6 on a
2.6.x kernel)
Berg, Michael
I logged in as root on the console (with the functional libnss-ldap_220-1
installed), upgraded to libnss-ldap_238-1 (which I'm having problems with),
and then started a new login process inside gdb.
When root attempts to log in through the debugged login process, here are
the results:
====================
...(snip)...
login: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
---Type <return> to continue, or q <return> to quit---
(I hit <return> to continue)
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208270176 (LWP 8911)]
0xffffe410 in __kernel_vsyscall ()
====================
I then ran a stack backtrace and obtained the following:
====================
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x41041805 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x41042f82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x4103b2a8 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4 0x411799fc in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#5 0x410fcaef in pthread_mutex_lock () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7dfdca1 in ldap_start_tls_s () from /usr/lib/libldap.so.2
#7 0x41daed03 in gcry_sexp_canon_len () from /usr/lib/libgcrypt.so.11
#8 0x41daee41 in gcry_sexp_canon_len () from /usr/lib/libgcrypt.so.11
#9 0x41dbbb3e in gcry_randomize () from /usr/lib/libgcrypt.so.11
#10 0x41db76b5 in gcry_md_algo_name () from /usr/lib/libgcrypt.so.11
#11 0x41db77b2 in gcry_md_open () from /usr/lib/libgcrypt.so.11
#12 0x41c4cffc in _gnutls_hash_init () from /usr/lib/libgnutls.so.11
#13 0x41c467f1 in gnutls_handshake () from /usr/lib/libgnutls.so.11
#14 0xb7c5dcb5 in gnutls_SSL_free () from /usr/lib/libldap_r.so.2
#15 0xb7c5ddda in gnutls_SSL_connect () from /usr/lib/libldap_r.so.2
#16 0xb7c5b68e in ldap_pvt_tls_init_def_ctx () from /usr/lib/libldap_r.so.2
#17 0xb7c5c696 in ldap_int_tls_start () from /usr/lib/libldap_r.so.2
#18 0xb7c5cb18 in ldap_start_tls_s () from /usr/lib/libldap_r.so.2
#19 0xb7c6962e in ?? () from /lib/libnss_ldap.so.2
#20 0x080a0218 in ?? ()
...(a whole lot of "?? ()" entries like #20 followed)...
====================
Hopefully this will help in tracking down the problem. If there are any
additional tests or debugger output you would like, let me know.