Subject: Re: Locking: Crispin wins, but I need more info

From: [email-masked] (brian moore)
Date: 18 Apr 1997 20:59:24 GMT

In article <[email-masked]>,
	[email-masked] (Ken Weaverling) writes:
> I have previously disagreed with the idea of having the mail spool
> writable by all because of fear of users plugging in files for missing
> (mainly new accounts) mail files in that directory, possible
> denial-of-service by loading it with crap, etc...

See below :)

> While trying to get over my stubborness, I figured that this guy is doing
> a lot of work without us paying him a cent, so he deserves to do it the
> way he wants.

Well, it's not just Mark... it's the way a LOT of systems have done things.
Even Berkeley, and I know Mark isn't too fond of them from his comments
in the c-client library. :)

> So, I am reconfiguring everything to allow my /var/mail to be 1777 which
> includes changing my vendor-provided sendmail, local delivery agent, etc.

You almost always want to junk your vendor provided sendmail.  Solaris, for
example, ships with a mystery version of sendmail that has weird god-awful
hacks in it so that it can run with the same config file originally written
in 1937 or so.  If you use your own compilation you can at least know what
it is and keep it current easily.

> How can I ensure safety of user mail in the mail spool? I am going to use
> procmail for local delivery. He seems to be pretty paranoid about the
> inbox permissions. For example, if I create a spool file for a missing
> user with more than 600 perms, it changes it to 600. If I create a spool
> file with 600 but owned by another user, procmail renames it to BOGUS.*
> and delivers to a fresh inbox. Seems fine so far. Am I missing something?
> I'd rather not create empty spool files when an account is created, since
> about 50% of our student accounts are never accessed which means the mail
> spool directory entry would be larger than it has to be.

Procmail is a wonderful choice for a delivery agent.  It is VERY paranoid
and behaves itself better than most programs, which is perhaps what's
confusing you about the BOGUS files.  If you don't mail the user, procmail
won't create ANY file at all.  But if it finds one and it's not owned by
the proper user, it's renamed.  This is so you can't have userbob put in
a fake mail file for userjohn if John has a broken client that erases his
mailbox when he cleans it.

If procmail didn't move it out of the way, you'd run into other issues, like
who should own the file, should procmail still have root at that point to
chown the file, etc.

Steven seems to have done a lot of thought on that and I'm comfortable with
its handling and how early procmail gives up root.

> procmail seems to lock by creating a username.lock file while the UW imap4 
> creates username.lock with loads of digits and stuff after it. I assume
> these two guys will not trip over each other?  What about the pine 
> native (non-imap) client?

Ah, the world of Unix file lockings... :)  Try procmail -v and it'll tell
you what file locking it wants to do.  If installed right, it will do every
kind of file locking it can... dotlocks, fcntl, lockf and flock, hoping that
your clients will use one of them.

Clients compiled with the c-client library (which includes pine, imapd and
ipop3d) will do various types of locks as well (a quick check shows flock,
dotlock, and others.... The lock with the digits/etc are temporary locks
on the way to being a dotlock.  Look at bezerk_lock() in c-client/bezerk.c
for the details. :)

Yes, they seem to work fine together.

> Thanks. I'm a bit paranoid about mailbox safety. I *do* see the logic in
> not trusting stuff to have sgid mail privileges so this probably makes
> sense in the long run.  If someone abuses the writability of the spool,
> I'll resort to old fashioned "break their legs" technology!

Paranoia is good.  So is violence.  But I use procmail and imapd and ipop3d
here and have no problems with them locking.  The only problem is people
using broken clients that open the pop mailbox twice, but Mark's method on
that works better on IE2.0 which could do the same thing, and since most
of our customers are using IE in some flavor, that's fine by me.

-- 
Brian Moore                      The opinions expressed above are my own, not
Sysadmin, C/Perl Hacker          necesarily my employers'.

---

From: [email-masked] (Andrew P. Steingruebl)
Date: Wed, 23 Apr 1997 17:44:10 GMT

In article <[email-masked]>,
Mumit Khan <[email-masked]> wrote:
>
>We have found (5) to be the most stable and feasible solution, not to
>mention the most robust one. Our mail server forwards all mail to
>file servers where the user's home directory is (automated via simple
>NIS+ maps), which then uses procmail to deliver to user's home directory.
>Trivial configuration and no more problems with funny NFS locking and all
>that. Totally secure as well. 3+ years and still going.
>
>

So, you're aliasing usernames so that their mail goes to the same
server their home directory is on?

If so, are those same file servers the machines that user's log
directly into? 

If not, you're going to have the same locking problems when your MUA
doesn't lock correctly across NFS when a delivery is occuring, or is
all mail access then via IMAP?

Just curious..

-- 
*****************************************************************************
* Andy Steingruebl              | e-mail: [email-masked]        *
* Academic Computing Services   | phone:  (773) 702-7575                    *
* Unix Systems Admin/Programmer | fax:    (773) 702-3219                    *