Bug 10678 - Permissions on /var/spool/mail
Summary: Permissions on /var/spool/mail
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: imap
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-04-09 11:18 UTC by Peter Hunter
Modified: 2007-04-18 16:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-07-30 23:20:18 UTC
Embargoed:


Attachments (Terms of Use)

Description Peter Hunter 2000-04-09 11:18:27 UTC
pop3d seems to want permissions 1777 on /var/spool/mail so that it

can create lock files. linuxconf still wants /var/spool/mail to be 0775

(or something similar).

Comment 1 rog 2000-05-14 01:29:59 UTC
The 1777 is explained in the IMAP FAQ:

 http://www.washington.edu/imap/IMAP-FAQs/FAQ-00013.html

  " In order to update a mailbox in the default UNIX format,
    it is necessary to create a lock file to prevent the
    mailer from delivering mail while an update is in
    progress.  Some systems use a directory protection of
    775, requiring that all mail handling programs be
    setgid mail; or of 755, requiring that all mail
    handling programs be setuid root. The IMAP toolkit
    does not run with any special privileges, and we plan
    to keep it that way."

Comment 2 Peter Hunter 2000-05-15 16:16:59 UTC
Two points: (a) it is much more security conscious to use a short suid or sgid
wrapper than to have a world-writeable directory. (Think hard links.)
(b) If Redhat decides that 1777 are the right permissions for /var/spool/mail,
then they should update the list of permissions in linuxconf.

Comment 3 Andreas Metzler 2000-05-17 11:40:59 UTC
imap- and pop-daemon run SGID mail on redhat 6.2:
$:> ls -l /usr/sbin/{imapd,ipop3d}
-rwxr-xr-x  1 root mail  661376 Mar  2 00:47 /usr/sbin/imapd
-rwxr-xr-x  1 root mail  623904 Mar  2 00:47 /usr/sbin/ipop3d

      cu andreas

Comment 4 Peter Hunter 2000-05-17 11:56:59 UTC
No Andreas - look more closely: the binaries are owned by the mail group but
the SGID bit isn't set. The perms for both are rwxr-xr-x not rwxr-sr-x

Comment 5 Jonathan Kamens 2000-06-02 02:39:00 UTC
A related problem is that the "filesystem" RPM doesn't have /var/spool/mail mode
1777.  If you decide that in fact the directory should have that mode, the
filesystem RPM needs to be updated.


Comment 6 Alan Cox 2000-08-05 01:53:53 UTC
It should not be 1777, someone needs to check the sgid mail flags on the
binaries.


Comment 7 Cristian Gafton 2000-08-09 02:28:46 UTC
assigned to the new owner


Comment 8 Mike A. Harris 2001-07-30 23:20:10 UTC
This was either misassigned to nalin, or was not reassigned to me
when I began maintaining imap.  Reassigning...

The /var/spool/mail permissions are properly set to 755 which is correct.
This operation is intended, and the warning messages have been squelched
in the respective packages.

linuxconf is deprecated.

Comment 9 Anil Gangolli 2004-02-16 22:29:36 UTC
If these messages were really squelched, it looks like there is a 
regression in RedHat Enterprise Linux ES 3.0 Update 1.   I am seeing 
log messages of the form:

Feb 16 14:23:16 sycamore ipop3d[8976]: Mailbox vulnerable - 
directory /var/spool/mail must have 1777 protection

The package is imap-2002d-2.rpm from the ES 3.0 Update 1 distribution.

The /var/spool/mail directory is (as installed in ES 3.0 Update 1):

drwxrwxr-x    2 root     mail         4096 Feb 16 
14:21 /var/spool/mail

I was not seeing these when running 7.2 (with all updates), which I 
was running until 2/15/04.

Comment 10 Mike A. Harris 2004-02-17 02:54:11 UTC
This bug report is very ancient and for a no longer supported
OS release.  If you are experiencing a problem that is similar,
file a brand new bug report in bugzilla along with the relevant
details, flagged against the product and version you are using.

Thanks.


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