Subject: Re: Mail and locking
To: Greg A. Woods <email@example.com>
From: Jim Wise <firstname.lastname@example.org>
Date: 12/04/1996 18:43:25
On Wed, 4 Dec 1996, Greg A. Woods wrote:
> If the local delivery and mail-pickup processes are setgid to the unique
> member-less group which owns and has write permission on /var/mail, and
FWIW, I think it is a _bad_ idea to require this. It immediately raises two
problems in the porting of mail packages to NetBSD:
1.) Users cannot port mail agents without the help of the admin
staff. I think this is an unnecessary restriction... In the
past, I have often had reason to, for example, install a mail
reader, or, say, procmail on a machine I had only a user account
2.) The admin staff must do a lot more work to provide a new mail
program. Many mail programs were not designed to be run sgid/suid
and would not adapt well to this (would need shell escapes
removed or wrapped up, for example). Even those that were would
need a good going-over before I would suid them on any sytem
3.) It doesn't work well in an NFS environment.. It is unwise to
depend on sgid/suid access in an environment where the mail
spool may be mounted from another OS or where the client may
not be trusted...
> the system supports the POSIX notion of giving away files on quota-less
> filesystems, and /var/mail is on such a filesystem, then life with
But BSD doesn't, and I can think of _no_ good reasons that /var/mail should
be required to be quota-less. In fact, that strikes me as asking for trouble.
> mailers can become very mundane and routine with few risks to anyone.
> Of course it also helps if the delivery process can enforce local policy
> too, such as maximum mailbox sizes with decent bounce explanations; and
> if there's an ftruncate() system call.... If you can't give away a
Of course it would be nice, but do you know of any delivery agents which
actually do this? (An honest question -- I've never seen any that do.)
> file on a given system, then the only change to this schema is that
> mailboxes must be created by root instead of by the mailman, and must
> never be removed.
Another point where you seem to be requiring more work for no real gain...
> Maybe we can blame all the CERT sendmail advisories on the silly need to
> support the filesystem quotas so rarely used in practice. [0.5 ;-)]
So rarely used? I've _never_ run a general use system without mail quotas,
and know of noone doing so!
> Please be very careful how you define "reliable" here. It is extremely
> reliable when the correct algorithm is implemented properly. What
> you're saying is only that many people cannot write correct code the
> first few times around. There's nothing new in that!
I fail to see how your approach helps this...
GSAPP, Columbia University
* Finger for PGP public key *