Path: utzoo!yunexus!ists!mike
From: mike@ists (Mike Clarkson)
Newsgroups: comp.mail.misc
Subject: Re: central mail server
Summary: suid root breaks across nfs
Keywords: mail NFS
Message-ID: <226@ists>
Date: 12 Oct 88 01:12:47 GMT
Article-I.D.: ists.226
References: <363@asuvax.UUCP> <464@Terra.cc.brunel.ac.uk> <9449@swan.ulowell.edu> <1431@xyzzy.UUCP>
Organization: Institute for Space and Terrestrial Science
Lines: 53

In article <1431@xyzzy.UUCP>, meissner@xyzzy.UUCP (Usenet Administration) writes:
> When some mail agent (/bin/rmail to deliver new mail, or any of
> mailx/Mail/mh/elm to delete old mail) wants to modify the mailbox for
> a user "joe", it creates a file in the spool directory with ".lock"
> tacked on (/usr/spool/mail/joe.lock for BSD systems,
> /usr/mail/joe.lock for system V), with options to open to fail if the
> file exists.
> 
> If the file exists, it means that some process is updating the
> mailbox, and the process loops for some period of time trying to gain
> access to the mailbox.  As soon as the mailbox is not being updated,
> the lock should be removed.  For example, when you read the mail, your
> mail reader should lock the mailbox, read the mail file into a private
> spool file, and unlock it immediately, and then let you read, delete,
> file, etc. the mail at your leisure.  At the end, it would do the lock
> again, do any changes, and unlock.

Other big problem is that your local delivery agent has to be able to
write into /usr/spool/mail to make the lock (or to send mail to someone
for the first time). Either /usr/spool/mail is mode 777, a *very*
nasty security hole, or your delivery agent is suid root.  Same goes
for you local mailbox reading programs (elm, movemail in gnu emacs, etc.)
who have to lock the mailbox against /bin/mail when they are fetching
the mail.  But suid root breaks across NFS for security reasons: root
becomes a no-priviledged user "nobody".

The way we got around this was to make /usr/spool/mail group daemon
writable, and made our delivery agents and fetchers sgid daemon.
sgid daemon works across NFS, so everyone's happy.  They all can
fetch and release the lock, and /usr/spool/mail is still write-protected.

> There are two problems with using flock/lockf/fcntl to lock the
> mailboxes, 1) until recently NFS did not allow locking; and 2) all of
> the other programs that dealt with locking (such as elm) would have
> to change as well (this has been a problem for elm in the past).

NFS supported file-locking with the lockd daemon (usually :-).
The problem is that /bin/mail had to be rewritten to to use the
new calls to the network locking.  This was done in 4.0, and at the
same time, the lockd bugs were alledgedly squashed.  I say alledgedly
because trashing unlocked mailboxes is a relatively rare occurence.
It takes bad timing, and it may be a little while before we see if
everything really works.  Note also that elm will have to be re-written
to take advantage of lockd.




-- 
Mike Clarkson					mike@ists.UUCP
Institute for Space and Terrestrial Science	mike@ists.yorku.ca
York University, North York, Ontario,		uunet!mnetor!yunexus!ists!mike
CANADA M3J 1P3					+1 (416) 736-5611