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): dovecot-0.99.11-2.EL4.1.x86_64 Additional info: http://dovecot.org/list/dovecot/2005-February/006237.html
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 release.
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 help.
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 pam_stack). Thanks.
Created attachment 138314 [details] dovecot Log file The usernames and IP are anonymized.
Created attachment 138315 [details] secure log
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 (mail-01).
This is the content of the file /etc/pam.d/dovecot at the time when the problem happened (26-27 of June): #%PAM-1.0 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: http://dovecot.org/list/dovecot/2005-February/006237.html about "- PAM crashed with 64bit systems", a problem existent in the previous versions. Thank You Davide Brunato
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