Subject: Bug#3901: "dotlock" should be setgid mail

From: [email-masked] (Avery Pennarun)
Date: Tue, 23 Jul 96 21:35 EDT

Package: tkmail
Version: 4.0beta7-

In my freshly-installed Debian 1.1 system, /var/spool/mail is setgid 
mail and only writable by members of the group.  I believe this is as 
it should be.

The problem is that tkmail comes set up to use dotlock files (ie. 
/var/spool/mail/apenwarr.lock) via an external program called dotlock.  
This program is not setgid mail, and thus cannot create the lock file, 
causing all kinds of mess when tkmail tries to do so.

On another note, the "dotlock" command duplicates the functionality of 
the "lockfile" command from procmail, and possibly other utilities.  
Perhaps some attempt should be made to standardize this in Debian? 

Have fun.

Avery

---

From: Mr Stuart Lamble <[email-masked]>
Date: Thu, 25 Jul 1996 07:55:50 +1000 (EST)

> mail and only writable by members of the group.  I believe this is as 

I don't. On the systems here at Monash:

mdw056_2% ls -ld /var/spool/mail
drwxrwxrwt  3 root        21504 Jul 25 07:50 /var/spool/mail
aurora.cc.monash.edu.au> ls -ld /var/spool/mail
drwxrwxrwt   2 root     system      24064 Jul 25 07:54 /var/spool/mail

It should be world readable/writeable, with the sticky bit set (ie,
mode 1777.) Several programs, such as elm, create lock files in that
directory.

-- 
I'm on a low-fat, high stress diet: coffee and fingernails.

---

From: Avery Pennarun <[email-masked]>
Date: Thu, 25 Jul 1996 13:27:03 -0400 (EDT)

On Thu, 25 Jul 1996, Mr Stuart Lamble wrote:

> I don't.

The quick answer is that Debian 1.1 does it that way, and this is the source
of my bug report.

But if we want to discuss it anyway (why not):

> On the systems here at Monash:
> 

If you do this, then any user can create arbitrary files in the mail spool
directory.  Yuck.

Programs which need to create lock files (the ONLY files other than
mailboxes which ought to be there, IMHO) can get setgid mail.  If you think
setgid'ing your mailreader is a security problem, then you're probably right
and it should be calling a nice, small program (smaller = more likely to be
secure) like "dotlock" or "lockfile" to do the lock/unlock for you.

Unfortunately, "dotlock" (from the TkMail package) is not setgid mail like
it needs to be, and thus can't do the job.  That was my bug report.

Also the duplication between dotlock (TkMail) and lockfile (procmail) is
rather pointless.  It would be nice to see _all_ the Debian mail reader
packages non-setgid and just use lockfile/dotlock.  (Plus it means we can
use a better locking method if one becomes available.)

Have fun,

Avery

---

From: Lars Wirzenius <[email-masked]>
Date: Mon, 29 Jul 1996 22:42:45 +0300

> If you do this, then any user can create arbitrary files in the mail spool

The same problem exists with lockfile (I don't know about dotlock).
Lockfile would need rather extensive checks built in so that it doesn't
let you create the wrong lock files.  

Anyway, the current lockfile is useful for locking outside the spool
directory (my mail fetching scripts use lockfiles in my home directory,
for example). We'd need a new program. Because of the restrictions, it
would have to be moderately complicated, which makes it tricky to get
right without opening security holes.

I can see three problems:

	- overcoming disk quotas
	- user FOO creating /var/spool/mail/BAR, and getting access to
	  BAR's mail
	- user FOO creating /var/spool/mail/BAR.lock, and preventing
	  BAR from reading his mail
	  
The first is not a problem.  Disk quotas can apply to the spool partition
and probably should, so that people won't use their mailbox as a way to
get around disk quotas (this has happened at my university--the perp's
are caught rather quickly, as it happens).  

The second should not be a problem,  Every user should have a mailbox.
Maybe the MTA should check ownerships, or at least a daily cron script
could do it (optionally, perhaps).

The third should not be too much of a problem.  Lockfile ownership
is enough to condemn the perp.

I think we should stay away from setuid and setgid programs, if possible.
They're difficult to get right.

FWIW, I think two better solutions to this permission problem is to
either user IMAP to access the folder (and never access the files in
the spool directory directly, only via the IMAP server), or forget the
spool directory and store incoming mail in the home directory of the user.
Since neither of these is really feasible for a stock Debian installation,
I suggest staying with rwxrwxrwt.