Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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