sreangsu acharyya rearranged electrons thusly:
> > I'm getting the following error on the server while accesing mails from a client.
> > "Mailbox vulnerable - directory /var/spool/mail must have 1777 protection"
> > the directory /var/spool/mail is owned by root.mail with 775 permissions.
^^^
> mutt being a responsible mua is warning you that anybody and everybody can
> read all the mails!!
This is not a mutt warning - it's generated by newer versions of Pine (4.2x and above).
Here's a quote from the PINE release notes (integrated into the client -
another reason for its huge bulk)
8<
1. Why did locking change in Pine 4.00?
The actual locking mechanisms did not change in 4.00. What changed is that when one
particular locking mechanism used by Pine fails, Pine now issues a warning
message. Prior
to 4.00, the locking failure would occur, but no warning was issued.
2. Is this what the "Mailbox vulnerable" message is about?
Yes. It means that Pine was unable to create a lockfile in the spool directory,
generally
because of overly restrictive protections on the spool directory. The correct
permissions
on the spool directory for running Pine are 1777, i.e. read-write-execute
permission for
everyone, with the sticky-bit set, so only owners of a file can delete them.
3. Why does Pine require that the mail spool directory have 1777 protections?
Pine was designed to run without special privileges. This means that in order to
create a
lockfile in the spool directory, it is necessary to have the spool directory
permissions
be world-writable.
4. Can't you create the lockfile somewhere else?
No. The lockfile in question must be in the mail spool directory, because that's
where
the mail delivery program expects to find it, and the purpose of the file is to
coordinate access between the mail client (Pine) and the mail delivery program.
5. Isn't having the spool directory world-writable a big security risk?
No. Remember that the individual mail files in the spool directory are NOT
world-writable, only the containing directory. Setting the "sticky bit" --
indicated by
the "1" before the "777" mode -- means that only the owner of the file (or root)
can
delete files in the directory. So the only bad behavior that is invited by the
1777 mode
is that anyone could create a random file in the spool directory. If the spool
directory
is under quota control along with home directories, there is little incentive for
anyone
to do this, and even without quotas a periodic scan for non-mail files usually
takes care
of the problem.
[snip]
--suresh
--
Suresh Ramasubramanian <--> mallet <at> efn <dot> org
EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
----------------------------------------------
An alpha version of a web based tool to manage
your subscription with this mailing list is at
http://lists.linux-india.org/cgi-bin/mj_wwwusr
