Subject: Problem with .lock mailbox locking

From: Jos Vos <[email-masked]>
Date: Mon, 18 Oct 93 16:09:16 MET

I noticed the following behaviour:

When I make my pine (on System V.3) setgid mail, it creates a lockfile
for the INBOX (/usr/spool/mail/jos.lock on our system).

In a non-setgid (non-setuid) mode, pine seems not to create a .lock
file (it can't, because it doesn't have the right to write in
/usr/spool/mail), but it doesn't complain!

Any explanation for this behaviour?

-- 
--    Jos Vos <[email-masked]>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

---

From: Mark Crispin <[email-masked]>
Date: Mon, 18 Oct 1993 11:57:01 -0700 (PDT)

> Any explanation for this behaviour?

Yes, there is an explanation.  Pine is not designed to run privileged, and
some sites (as a matter of policy) protect their /usr/spool/mail directories
so unprivileged processes can't create .lock files.

Pine uses two forms of locking: .lock files and the flock() call.  Both of
these are used by various versions of /bin/mail (which is what sendmail uses
for mail delivery).  Since Pine has no way of knowing which form of locking
mail delivery uses, it tries both.  Both forms have problems.

Because there are sites which deliberately, prevent the creation of .lock
files, Pine can only hope that /bin/mail uses flock() locking.  Otherwise, the
site's policy really is ``you can't have unprivileged programs accessing mail
files.''  On such a site, either you make Pine run privileged (and run the
risk with doing that), or take the risk of not having effective locking, or
you run Pine on another system.  :-(

Unfortunately, flock() (or lockf() on SysV) isn't a panacea either.

It's terribly annoying for Pine to issue zillions of error messages (we know;
our local computer center has the above policy) when there is nothing wrong
and flock() is covering Pine's rear.  Hence Pine's silence on this condition.

To summarize: Pine *tries* to do .lock file locking, and always does flock()
(or the SysV equivalent) locking.

The only other thing to do is to have some build configuration parameter in
the c-client library set what kind of locking to use.  There is a problem with
this.  In my experience, 98% of all the people who build Pine haven't a clue
of how to answer such a question, and the consequences of answering it wrong
are even worse than the current status quo.

We would appreciate suggestions of how to handle this any better.  We don't
think it is safe to make locking configurable; Pine should try all forms.  We
can hope that .lock file creation failure means ``don't use .lock files on
this system'', based on the assumption that the only other interpretation is
``only sysadmins can write/install mail programs on this system.''  We'd lock
to hear of any ``magic bullets'' that'll solve these problems!

---

From: Jos Vos <[email-masked]>
Date: Tue, 19 Oct 93 14:29:40 MET

> (or the SysV equivalent) locking.

Unfortunately, *trying* to lock means existing .lock files are
not honoured, isn't it?
So, when mail is just delivered to your INBOX, Pine doesn't matter :-(

---

From: Mark Crispin <[email-masked]>
Date: Tue, 19 Oct 1993 08:21:00 -0700 (PDT)

> So, when mail is just delivered to your INBOX, Pine doesn't matter :-(

No.

The decision to give up on .lock file locking happens at a very specific
point; that is, when an attempt is make to create a .lock file and the
operating system returns a ``protection violation'' (EACCES) error.

In ALL other cases, .lock file locking is enforced.  This includes the case
when there is an existing .lock file.

In other words, Pine will not tromp upon some other program which has the file
locked.  But, if Pine is unable to make the .lock file, some othe program may
tromp upon Pine.