Bug 103479 - Mailbox vulnerable - directory /var/spool/mail must have 1777 protection
Mailbox vulnerable - directory /var/spool/mail must have 1777 protection
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: imap (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
David Lawrence
:
: 109539 115903 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-31 18:52 EDT by Christopher McCrory
Modified: 2007-11-30 17:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:34:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher McCrory 2003-08-31 18:52:27 EDT
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
Comment 1 Jason Sauve 2003-11-21 11:28:34 EST
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. 
Comment 2 David Rubert 2004-01-15 06:08:58 EST
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? 
Comment 3 Mike A. Harris 2004-02-27 04:58:41 EST
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.
Comment 5 Mike A. Harris 2004-02-27 05:20:39 EST
*** Bug 115903 has been marked as a duplicate of this bug. ***
Comment 6 Mike A. Harris 2004-02-27 05:24:16 EST
*** Bug 109539 has been marked as a duplicate of this bug. ***
Comment 7 Mike A. Harris 2004-02-27 05:25:13 EST
Just a note, this problem is present in Fedora Core 1 also.  I've
duped both RHEL and FC bugs against this one.
Comment 8 David A. J. Ripley 2004-07-26 16:56:52 EDT
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
Comment 9 albunix 2004-10-12 15:27:39 EDT
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.
"

Comment 10 RHEL Product and Program Management 2007-10-19 15:34:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.