Red Hat Bugzilla – Bug 201333
Dovecot crash with PAM authentication
Last modified: 2009-11-05 09:02:31 EST
Description of problem: Default dovecot auth configuration (with PAM) fault with
mailbox privacy violation.
PAM crashes under medium/high load and the dovecot-imap/pop processes permit
users to access (download in case of POP3) other user's mailboxes.
Version-Release number of selected component (if applicable):
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Created attachment 137054 [details]
Extracted from log file of the server - 26-27th of June 2006
The server use a RHEL 4 Update 3 with Cluster Suite 4 and GFS 6.1 .
The cluster is composed by two server HP Proliant DL385 G4 with 4GB of RAM.
Crash log event reported:
dovecot-auth: Jun 27 10:52:33 Error: PAM: Child process died
dovecot-auth: Jun 27 10:52:39 Error: PAM: Child 21671 died with signal 11
After crash events of dovecot-auth subprocesses the IMAP/POP server permits some
(about 10 cases reported in front of ~500 mailboxes) users to download (with
POP) mails of another user.
Workaround: we are using dovecot-1.0b and use LDAP to authenticate the users.
Interesting, i have been sifting through the sources and the change you
mention in the original report seems to be completely unrelated to the error
from the log file you have posted. Could you please verify that 0.99.14 really
contains a fix for your problem? Also maybe a more complete log could be of
Also, could you please get me the relevant parts of /var/log/secure? And pam
config files related to dovecot (dovecot's itself and anything it uses through
Created attachment 138314 [details]
dovecot Log file
The usernames and IP are anonymized.
Created attachment 138315 [details]
Created attachment 138316 [details]
ps command output of 27-06-2006 at 5:12 AM
If useful. We have GFS+CS on this machine (mail-02) and on the other node
This is the content of the file /etc/pam.d/dovecot at the time when the problem
happened (26-27 of June):
auth required pam_nologin.so
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
It's identical to the current configuration.
Created attachment 138317 [details]
dovecot configuration 27-06-2006
We can't verify if the 0.99.14 because the cluster is in production.
Moreover we tested the dovecot-0.99.11-2 for several weeks before migrating to
the new e-mail server. No problems reported like the events of the 26-27 of
June. Probably the problem happens when the number of connected users is high
than we should test.
Now we run a dovecot-1.0 beta version (no problems reported) and wait for the
1.0 release to do an upgrade (it is a mantained version and has new features).
I found in the dovecot ML a resolved problem about 64 bits AMD systems:
about "- PAM crashed with 64bit systems", a problem existent in the previous
Do you use userdb ldap or user passwd with dovecot-1.0?
According to my investigation, the change in 0.99.14 is definitely not related
to this issue and I think the PAM crash in the log file is not related to the
issue with users seeing mails of other users neither. The crash should (and does
in here) just result in dovecot rejecting the login. It might be caused by
PAM/nss_ldap/whatever brokenness but should not make dovecot do anything bad.
On the other hand, the issue with users seeing mails of other users is a known
issue described in bug 154314. I suppose using userdb ldap instead of passwd
(nsswitch in fact) in dovecot should solve this issue.
Therefore, I propose to close this one and track the individual issues in bug
154314 etc. I will, however, try to workaround it according to bug 222110.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.
Seems like all this may be caused by the nss_ldap problem. I'm adding that as dep.
I'm not able to reproduce this bug. Based on this:
- fixed: 222110 - nss_ldap brokeness prevention attempt
- blocking bug has been already resolved
can you still reproduce this problem? If so, please provide any info useful for reproducing this. Thanks
this bug was in needinfo state for several months, closing
feel free to reopen if you can hit this bug and can provide requested information