Description of problem: Mailbox vulnerable - directory /var/spool/mail must have 1777 protection Version-Release number of selected component (if applicable): [chrismcc@taroon32 chrismcc]$ rpm -q imap imap-2002d-2 How reproducible: check email via pop Steps to Reproduce: 1. install and enable imap 2. 3. Actual results: [chrismcc@taroon32 SRPMS]$ telnet localhost 110 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. +OK POP3 localhost v2003.83rh server ready user test-pop +OK User name accepted, password please pass test +OK Mailbox open, 0 messages ==> maillog <== Aug 31 15:51:13 taroon32 ipop3d[2763]: Mailbox vulnerable - directory /var/spool/mail must have 1777 protection Aug 31 15:51:13 taroon32 ipop3d[2763]: Login user=test-pop host=localhost [127.0.0.1] nmsgs=0/0 Expected results: no 1777 message Additional info: IIRC, this was fixed via a RH patch a while back
It would appear as though IPOP3 falls back on another locking mechanism (flock). If you telnet to your mail server on port 110 and leave the connection sit idle, you will see that there is a lock file generated in /tmp (with the uid/gid of the ipop3d authenticated user), the contents of the lock file correspond to the PID of the running ipop3d process. In addition, I looked at the source RPM and saw that there is a flock.c patch that Redhat applies to the compiled binary RPM for imapd/ipop3d. I wouldn't worry about the error message too much, as there is another locking mechanism in place, it would just be nice to not have to see that error message all the time, plus I really don't think I should have to chmod 1777 /var/spool/mail for no reason at all - regardless of whether or not it lessens security by allowing anyone to create files with gid mail in the spool dir.
From the wu-imap FAQ, they say that you have to set the /var/spool/maildirectory to 1777 permissions, or use a lock program called "mlock"(setgid mail), enabled by the Makefile variable LOCKPGM). In the process of the rpm build, the redhat patch"imap-2000-linux.patch" disables this variable, so imapd makes no use of a external lock program, producing the message of the mailbox vulnerable. Which is the redhat recommendation in this case? It would be safe to re-enable the mlock program?
This warning message from UW imap is 100% bogus. Red Hat does not use the same locking mechanism that is recommended by the UW imap people, because it is inherently more insecure. All software on the system which accesses the mail spool files must agree upon a common locking mechanism, and must be patched if necessary to all use one single mechanism. Red Hat has been using the same mechanism in all OS releases for many years now, and we have patched UW imap, and UW pine to use our system-wide mechanism for some time now. UW suggests that the mail spool directory should be mode 1777, which is incredibly insane, as that makes the mail spool directory *world writeable*, and thus subject to local DOS attacks. That is totally unacceptable in a modern Linux/UNIX OS. The proper fix for this bug, is to patch the UW imap sources to remove this bogus warning/error message, because we do not use the insecure method that UW recommends for mail locking. Doing otherwise, would require patching every single MTA, MDA, and MUA in the entire distribution to do it the ensecure world-writeable way, and we decided a very long time ago that that was not acceptable.
*** Bug 115903 has been marked as a duplicate of this bug. ***
*** Bug 109539 has been marked as a duplicate of this bug. ***
Just a note, this problem is present in Fedora Core 1 also. I've duped both RHEL and FC bugs against this one.
A workaround is to create /etc/c-client.cf containing the following 2 lines: I accept the risk set disable-lock-warning 1 This will quell the warning message for all users. The warning can be prevented on a per- user basis by having "set allow-user-config 1" in /etc/c-client.cf, and individual users including the disable-lock-warning directive in their .imaprc file
from /usr/share/doc/imap2002d/bugs.txt ". /tmp, /usr/tmp or /var/tmp (if present), and the mail spool directory must be protected 1777 (world write with sticky bit); otherwise mailbox locking and updates won't work. "
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.