The problem relies in the fact that if an application is linked against pthread and uses a nss_ldap call and then forks, both processes share the ldap connection, having no locking mechanism, and bad things happen. This is the case with dovecot -- dovecot-auth is linked with pthread and uses pam in forked processes. A race condition causes dovecot-auth to receive a reply that should have gone to pam. The direct cause of this is that an assumption that __pthread_once is nonnull (ldap-nss.c:1048) implies __pthread_atfork being nonnull (ldap-nss.c:504, bits/libc-lock.h:290) is plain wrong. These two variables have no connection to each other and each of them becomes non-null at the time linker resolves them, which happens upon them being called. And it happens upon them being called in the object that checks for them -- that means calling pthread_atfork in dovecot has no effect on __pthread_atfork value in nss_ldap and vice versa. For some not so obvious reason __pthread_once is nonnull at the enter of main function, __pthread_atfork is null. This means that nss_ldap assumes we have pthreads working, calls the __libc_atfork (ldap-nss.c:504), which is a noop in this case, and then has no idea about the forks and such. The easiest solution would be to help nss_ldap's configure find pthreads (telling it to -lpthread), which would make nss_ldap use pthreads directly and avoid such crazy things -- and using those libc internal functions is bad anyway, but I'm not sure whether we should do it. Also, we could fix it to chech for both __pthread_once and __pthread_atfork but it would not find them and use the pid-comparing method, which is probably slower. I hope this information helps :)
ldap-bugs please advise.
Both patches on the RH Bugzie URL are already present upstream as of nss_ldap-256, so all we need to do is stabilize nss_ldap-257.2 (which has been in the tree 29 days already). I'm aware of bug 198408 that was a build weirdness, and bug 165638 for the kerberos folk - but neither of these should hold back 257.2 going to stable. Also, this raises bug 197467 to being security critical, you'll have to chase amd64 there to bump that package and stabilize/issue GLSA.
minor update, I just put nss_ldap-258 into the tree, it contained a singular upstream change (5 lines only) fixing nss_srv_domain usage, and I put the kerberos fix in at the same time, and hopefully resolved the build bug 198408. It may be a better candidate than 257.2 for that reason.
(In reply to comment #3) > and hopefully resolved the build bug 198408. > It may be a better candidate than 257.2 for that reason. Let's wait for a reply for today. > Also, this raises bug 197467 to being security critical, you'll have to chase > amd64 there to bump that package and stabilize/issue GLSA. I added it to our emul-baselibs bug 196865.
rbu/security: bug 198408 resolved and 258 works for that user now, you can go for stabilizing 258.
Thx Robbat. Arches please test and mark stable. Target keywords are: nss_ldap-258.ebuild:KEYWORDS="alpha amd64 hppa mips ppc ppc64 sparc x86"
Stable for HPPA.
ppc64 stable
x86 stable
alpha/sparc stable
ppc stable
amd64 stable
Voting YES because of the high impact of dovecot returning wrong inboxes.
yes too, request filed.
GLSA 200711-33
