Subject: Re: /var/spool/mail must have 1777 protection

From: Nicolas Markey <[email-masked]>
Date: Wed, 1 Dec 1999 09:56:04 +0100 (MET)

On Wed, 1 Dec 1999, Ariel wrote:

| 2775 would allow any user who can create a file in the spool to also
| delete any file in the spool even if they don't own the file so it's not
| safe. If you want new files to get the group of the directory (2000) at
| least do 3775. (i.e. also add 1000) so that you have the sticky bit set as
| well.
| 
| Hopefully whatever group you have for the directory includes all your
| users who might use mail or you'll run into problems.

Well. Actually that's not the case. /var/spool/mail is owned by
root.mail, so that no user can create nor delete a file (except
root) because there is no user in the "mail" group. Only the "mailer
dameon" can create (or delete) a file there. 

I agree 3775 is theoreticaly better, but my opinion is that 1777 is
not safe : with 1777 any user can create a file in /var/spool/mail,
thus any user could make the partition full and we would run into
troubles.

Thanx for your help.

--  Nico

---

From: Seth Kurtzberg <[email-masked]>
Date: Wed, 1 Dec 1999 07:59:49 -0700 (MST)

/var/spool/mail should be read only for "other" (whatever that changes the
last 7 to).  This works fine with Pine.

Seth Kurtzberg
Machine Independent Software
Cell (602) 478-5511
Fax: (480) 614-8909
email:  [email-masked]
pager:  888-605-9296 or email [email-masked]

---

From: Terry Gray <[email-masked]>
Date: Wed, 1 Dec 1999 08:49:55 -0800 (Pacific Standard Time)

> thus any user could make the partition full and we would run into

Nico,
I've always been curious why folks believe that 1777 is unsafe because
it allows anyone to create files... since you don't even have to have an
account on the system to fill up a mailspool (and those with accounts can
already use /var/spool/mail for temporary storage via mail software).

Can you elaborate on your view?

-teg

p.s. I believe there is a section in the release notes and also the FAQ on
why the spool directory needs to be 1777.  Look for "Folder Locking".

---

From: Ariel <[email-masked]>
Date: Wed, 1 Dec 1999 13:42:03 -0500 (EST)

> dameon" can create (or delete) a file there. 

If only your daemon can create files in the mail spool that you are
running a _severe_ risk of corrupting your users mail. In order to lock
the mail file the mail program must be able to create a <username>.lock
file, if it can't, then most likely your mail file is not locked when a
user saves his mail (expunge in pine). If that user should happen to get
mail by the daemon at that moment, both programs will try to write to the
mail file simultaneously causing major corruption. (The new message will
be interleaved with another message.)

There are a lot of warnings about running mail without lock files. Even
when you use kernel locking, it's not always reliable, and doesn't work
with NFS.

> thus any user could make the partition full and we would run into

3775 is not theoretically better, it is better, if you have users in the
mail group. If not then use 3777. The fact that users can create files in
the mail spool is well known in unix, and there are tons of solutions.

Here are a few. Set it to 3775, and make any program that might do mail
setgid to mail. That way mail programs can create any file necessary in
the mail spool, while ordinary users can not. This is not perfect since
you can trick the mail program into writing things in the mail spool for
you, but it's harder, and unless someone explicitly wants to cause trouble
it won't happen.

You can run quota on the mail spool with some large limit.

One popular choice if to have a program that once a day looks for any file
with a length greater then 0, and if found, moves it into the users home
directory. (Not including the mail itself of course.) (Greater then zero
to avoid moving lock files.)

Some places put all mail files in ~/.mail instead of /var/spool/mail, if
you make this change you'll have to recompile all your mail readers.

And of course you can do what the majority of systems do, and not worry
about filling up space. After all a user can fill up /tmp and /var/tmp and
cause you just as much if not more trouble. There comes a point where you
have to trust users not be idiots. Also it's generally agreed that trying
to prevent DOS (denial of service) attacks usually hurt legitimate users
more then the attackers.

And becides, if they were trying to cause trouble, they could just make
their mail file very large.

	-Ariel

---

From: Seth Kurtzberg <[email-masked]>
Date: Thu, 2 Dec 1999 08:04:37 -0700 (MST)

It is true that if there were **absolutely no security holes** on the
system, then the permission issue would be moot.  Unfortunately, this is
never the case.  I don't want to describe existing security holes, but
they do exist, and opening up permissions in a mail related directory is
one of the most dangerous things that you can do, as email is the source
of the majority of security breaches.

Seth Kurtzberg