degennar(_at_)bmsrs(_dot_)usc(_dot_)edu (Ray DeGennaro (@Home via Eudora))
writes:
Ok, I checked both elm (elm -v) and procmail (procmail -v) and the both use
dotlocking and fcntl() and procmail also uses lockf(). Does that mean that
if I use the following recipe to write to my system mailbox:
#the popserver uses the file /tmp/.<username>.pop
:0:/tmp/.$LOGNAME.pop
$DEFAULT
procmail will use fcntl() and lockf() (but not dotlocking) and I shouldn't
get a collision with either elm (due to fcntl()), nor the popserver (using
the same lockfile)?
What if elm and popserver clash?
Actually, the pop server probably does dotlocking using $MAIL.lock
and/or fcntl() locking; the /tmp/.$LOGNAME.pop file is not actually a
lockfile in any implementation I know, but rather the fixed name of the
temporary file. Looking at the qpopper-2.2 source I see that it
doesn't care whether or not the /tmp/.$LOGNAME.pop file exists, and in
fact it leaves the file there when it exists, thus making it totally
unsuitable as a lockfile. (qpopper _does_ use fcntl locking on $MAIL,
as well as /tmp/.$LOGNAME.pop, and, on Solaris, it also does dotlocking
using $MAIL.lock, as implemented by Solaris's libmail.)
Also, one of the comments about 3.11pre4 says that it allows users that
can't write to the system mail directory to lock their mail file. Does
refer to the use of both fcntl() and lockf()? Or is there another scheme
in 3.11pre4?
Neither fcntl() nor lockf() require the ability to write to the spool
directory: only dotlocking requires that. What you're refering to is
the fact that if procmail is installed setuid root or setgid to
whatever group the mail directory is owned by, then it can perform
dotlocking with the special permissions in a secure fashion. The
lockfile command can do this as well, assuming it was installed with
such permissions as well.
Philip Guenther