Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 9987 - /var/spool/mail must have 1777 protection
Summary: /var/spool/mail must have 1777 protection
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: x86 Linux
: High normal
Assignee: Nick Hadaway
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-30 17:24 UTC by ajacoutot
Modified: 2003-02-04 19:42 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ajacoutot 2002-10-30 17:24:57 UTC
Hi,

After installing postfix+uw-imap, I get the following error in mail.log:

Mailbox vulnerable - directory /var/spool/mail must have 
1777 protection

I did a chmod 1777 on it and now it works with no error, but don't you think
this should be the default rights on a typical Gentoo installation ?
--> that would be easier.
Or am I wrong ?
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2002-11-02 00:36:43 UTC
Martin please e-mail me.
Comment 2 Nick Hadaway 2002-11-17 16:20:54 UTC
/var/spool/mail is not used with postfix so the directory permissions warning 
can be safely ignored.

What program is putting the log messages saying to change the directory 
permissions?  Pine?
Comment 3 ajacoutot 2002-11-18 01:45:07 UTC
I guess that must be either uw-imapd or procmail. 
Comment 4 Nick Hadaway 2002-12-02 00:39:13 UTC
1777 is not safe.  Upon recieving this warning message you can choose to heed it
or do nothing and your setup should still work fine.  I think defaults are 0600.
Comment 5 ajacoutot 2002-12-02 03:02:52 UTC
I found something (from the uw-imapd FAQ):

What does the message:  Mailbox vulnerable - directory /var/spool/mail must have
1777 protection mean? How can I fix this?

    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 I plan to
keep it that way. It is antithetical to the concept of a toolkit if users can't
write their own programs to use it. Also, I've had enough bad experiences with
security bugs while running privileged; the IMAP and POP servers have to be root
when not logged in, in order to be able to log themselves in. I don't want to go
any deeper down that slippery slope.

    Directory protection 1777 is secure enough on most well-managed systems. If
you can't trust your users with a 1777 mail spool (petty harassment is about the
limit of the abuse exposure), then you have much worse problems then that.

    If you absolutely insist upon requiring privileges to create a lock file,
external file locking can be done via a setgid mail program named /etc/mlock
(this is defined by LOCKPGM in the c-client Makefile). If the toolkit is unable
to create a <...mailbox...>.lock file in the directory by itself, it will try to
call mlock to do it. I do not recommend doing this for performance reasons.

    A sample mlock program is included as part of imap-2002. We have tried to
make this sample program secure, but it has not been thoroughly audited.