Hi dovecot, I am using the debian dovecot packages on a system running LDAP. My /etc/pam.d/common-* looks like this, which simply means try /etc/passwd first, and try LDAP using the same password if it is failed. account [success=1 default=ignore] pam_unix.so account required pam_ldap.so use_first_pass account required pam_permit.so auth [success=1 default=ignore] pam_unix.so auth required pam_ldap.so use_first_pass auth required pam_permit.so session [success=1 default=ignore] pam_unix.so session required pam_ldap.so use_first_pass session required pam_mkhomedir.so skel=/etc/skel umask=0002 session required pam_permit.so When many LDAP users login, /var/log/auth.log shows many (expected) error like: (note "pam_unix") Feb 3 18:16:15 eta dovecot-auth: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=127.0.0.1 Feb 3 18:16:19 eta dovecot-auth: (pam_unix) check pass; user unknown After recent upgrades from probably 0.99.10 to 0.99.13, these lines begin to appear in /var/log/mail.log: Feb 3 16:31:00 eta dovecot-auth: Login process has too old (123s) requests, killing it. Feb 3 16:31:00 eta dovecot-auth: Login process has too old (124s) requests, killing it. And some more like this, which shows the problem: Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (13) Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (14) Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (15) The problem can be solved by changing /etc/pam.d/dovecot to: auth required pam_ldap.so account required pam_ldap.so session required pam_mkhomedir.so skel=/etc/skel umask=0002 session required pam_ldap.so This change means PAM not fail auth for /etc/passwd again. I think dovecot has some problem dealing with the pam_unix + pam_ldap configuration. Do you have any idea? I am Cc-ing this message to the corresponding bug in Debian BTS. -- Regards, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://dovecot.org/pipermail/dovecot/attachments/20050203/e05e0d7e/attachment-0003.html>
On 2005-02-03 23:59, Alan Tam wrote:>Hi dovecot, > >I am using the debian dovecot packages on a system running LDAP. > >My /etc/pam.d/common-* looks like this, which simply means try /etc/passwd first, and try LDAP using the same password if it is failed. > >account [success=1 default=ignore] pam_unix.so >account required pam_ldap.so use_first_pass >account required pam_permit.so >auth [success=1 default=ignore] pam_unix.so >auth required pam_ldap.so use_first_pass >auth required pam_permit.so >session [success=1 default=ignore] pam_unix.so >session required pam_ldap.so use_first_pass >session required pam_mkhomedir.so skel=/etc/skel umask=0002 >session required pam_permit.so > >When many LDAP users login, /var/log/auth.log shows many (expected) error like: (note "pam_unix") >Feb 3 18:16:15 eta dovecot-auth: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=127.0.0.1 >Feb 3 18:16:19 eta dovecot-auth: (pam_unix) check pass; user unknown > >After recent upgrades from probably 0.99.10 to 0.99.13, these lines begin to appear in /var/log/mail.log: > >Feb 3 16:31:00 eta dovecot-auth: Login process has too old (123s) requests, killing it. >Feb 3 16:31:00 eta dovecot-auth: Login process has too old (124s) requests, killing it. > >And some more like this, which shows the problem: >Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (13) >Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (14) >Feb 3 16:45:23 eta dovecot-auth: I/O leak: 0x8054940 (15) > >The problem can be solved by changing /etc/pam.d/dovecot to: >auth required pam_ldap.so >account required pam_ldap.so >session required pam_mkhomedir.so skel=/etc/skel umask=0002 >session required pam_ldap.so >This change means PAM not fail auth for /etc/passwd again. > >I think dovecot has some problem dealing with the pam_unix + pam_ldap configuration. Do you have any idea? > >I am Cc-ing this message to the corresponding bug in Debian BTS. > >Solved by configuring dovecot to directly authenticate from LDAP. I still think it is your bug though. It is not a good solution anyway, since your LDAP authenticator doesn't support auth-bind. So I've to convert all userPassword into {CRYPT} format for it to work. -- Regards, Alan Answer: Because we read from top to bottom, from left to right. Question: Why should we put replies after the original text? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://dovecot.org/pipermail/dovecot/attachments/20050313/09a87da6/attachment-0003.html>
On Thu, 2005-02-03 at 23:59 +0800, Alan Tam wrote:> After recent upgrades from probably 0.99.10 to 0.99.13, these lines begin to appear in /var/log/mail.log: > > Feb 3 16:31:00 eta dovecot-auth: Login process has too old (123s) requests, killing it. > Feb 3 16:31:00 eta dovecot-auth: Login process has too old (124s) requests, killing it...> I think dovecot has some problem dealing with the pam_unix + pam_ldap configuration. Do you have any idea?Did you upgrade anything else than Dovecot then? I just looked, nothing has changed in PAM code between 0.99.10 and 0.99.13. Also Dovecot can't know what PAM does internally. It just forks a new process which executes the PAM stuff, and the main process just keeps waiting for a reply and the PAM process dies then. The above "has too old requests" messages come because the PAM process gets stuck and never dies. I think this is an issue with the used PAM modules. Of course, it might have something to do with Dovecot as well, for example Dovecot and PAM modules using different versions of libraries (eg. openssl, cyrus-sasl, ..). Hmm. I should create a separate PAM checker binary for 1.0-tests anyway. That won't be linked against any libraries and hopefully we won't see any library conflicts after that. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050316/a7a485c8/attachment-0001.bin>