[Dovecot] dovecot and libnss-ldap
Hi,
I've been using dovecot 0.99.14 for a few years, with libpam-ldap and libnss-ldap, and never experienced any problem with those. I expect to soon switch to dovecot 1.0rc15 (or whatever gets available in Debian Etch, hopefuly dovecot 1.0), but I've seen some warnings against dovecot+libnss-ldap...
Is the problem with libnss-ldap a recent problem (I mean it was not a problem with older dovecot such as my 0.99.14)? Is it still a problem even with 1.0rc22? Is there any hope to have it fixed before 1.0?
Note that while most of the users I have to deal with are in my LDAP directory, a few ones are not and are in /etc/passwd. Hence, "userdb ldap" is probably not an option for me (and I'm quite happy with configuring all my servers with PAM and NSS).
Cheers,
Nicolas
On Mon, 2007-02-12 at 16:19 +0100, Nicolas Boullis wrote:
Is the problem with libnss-ldap a recent problem (I mean it was not a problem with older dovecot such as my 0.99.14)? Is it still a problem even with 1.0rc22? Is there any hope to have it fixed before 1.0?
No. The problem has always existed, and it can't be solved in Dovecot without completely redesigning dovecot-auth's PAM support. I probably will do that after 1.0 though.
Anyway the RedHat people figured out the bug a week ago. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154314
On Mon, 2007-02-12 at 19:10 +0200, Timo Sirainen wrote:
No. The problem has always existed, and it can't be solved in Dovecot without completely redesigning dovecot-auth's PAM support. I probably will do that after 1.0 though.
Nope, it was actually really easy: http://dovecot.org/list/dovecot/2007-February/019466.html
blocking=yes for either PAM or passwd will fix it.
Hi Timo,
Timo Sirainen wrote:
On Mon, 2007-02-12 at 16:19 +0100, Nicolas Boullis wrote:
Is the problem with libnss-ldap a recent problem (I mean it was not a problem with older dovecot such as my 0.99.14)? Is it still a problem even with 1.0rc22? Is there any hope to have it fixed before 1.0?
No. The problem has always existed, and it can't be solved in Dovecot without completely redesigning dovecot-auth's PAM support. I probably will do that after 1.0 though.
Anyway the RedHat people figured out the bug a week ago. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154314
That's really good news. But if I understand it correctly (not sure at all I do), the real problem lies in libnss-ldap, and your changes in dovecot would work around this bug. Is this correct?
Moreover, I tried tu use the reproducer from http://people.redhat.com/tjanouse/dovecot/154314/ldaptest.c on one of my Debian systems and (after I created the corresponing accounts in my LDAP directory) all I got was dots... Would it mean that for some reason Debian's libnss-ldap is safo to use with dovecot?
Thanks for writing dovecot, and for your continuing work to make it the best POP/IMAP server ever.
Nicolas
On Tue, 2007-02-13 at 10:57 +0100, Nicolas Boullis wrote:
Moreover, I tried tu use the reproducer from http://people.redhat.com/tjanouse/dovecot/154314/ldaptest.c on one of my Debian systems and (after I created the corresponing accounts in my LDAP directory) all I got was dots... Would it mean that for some reason Debian's libnss-ldap is safo to use with dovecot?
I guess that's possible. There was something in the thread about linking with/without pthread support that changed something. Or did you not link the tester with pthreads?
Timo Sirainen wrote:
On Tue, 2007-02-13 at 10:57 +0100, Nicolas Boullis wrote:
Moreover, I tried tu use the reproducer from http://people.redhat.com/tjanouse/dovecot/154314/ldaptest.c on one of my Debian systems and (after I created the corresponing accounts in my LDAP directory) all I got was dots... Would it mean that for some reason Debian's libnss-ldap is safo to use with dovecot?
I guess that's possible. There was something in the thread about linking with/without pthread support that changed something. Or did you not link the tester with pthreads?
I did compile with the exact command found in the comments of the file. On debian systems, I only got dots. I also tried on a RedHat systems and got a few exclamation marks, and a freeze after a few seconds...
I read that part about libnss_ldap being linked with/without pthread, but I did not really understand.
Anyway, looking at some build logs, I see: cc -g -Wall -O2 -fPIC -Wall -fPIC -o nss_ldap.so -shared -Wl,-Bdynamic -Wl,--version-script,./exports.linux ldap-nss.o ldap-pwd.o ldap-grp.o ldap-netgrp.o ldap-rpc.o ldap-hosts.o ldap-network.o ldap-proto.o ldap-spwd.o ldap-alias.o ldap-service.o ldap-schema.o ldap-ethers.o ldap-bp.o ldap-automount.o util.o ltf.o snprintf.o resolve.o dnsconfig.o irs-nss.o pagectrl.o ldap-sldap.o -lldap_r -llber -lgssapi_krb5 -ldl -lnsl -lresolv -lpthread
Hence, it looks like Debian's libnss_ldap is linked with pthread. But does this mean I am safe, even without the new "blocking=yes" option?
Nicolas
On Thu, 2007-02-15 at 12:30 +0100, Nicolas Boullis wrote:
Hence, it looks like Debian's libnss_ldap is linked with pthread. But does this mean I am safe, even without the new "blocking=yes" option?
Probably. But I think it's still a good idea to use blocking=yes with userdb passwd, since then it can do multiple authentication lookups concurrently.
participants (2)
-
Nicolas Boullis
-
Timo Sirainen