Subject: Re: Newbie locking questions

From: [email-masked] (Stephen R. van den Berg)
Date: Fri, 3 Mar 1995 18:20:59 +0100

Johnny Tolliver <[email-masked]> wrote:
>procmail successfully writes/appends the new mail to /usr/spool/mail/jxt.
>But these multiple attempts to create the log file until some give-up
>condition is met causes a delay and extra processing. The FAQ has the
>following to say about how to solve this problem. [My comments/questions
>are enclosed in square brackets, like this.]

>        - Some systems support the sticky bit on directories (when set only
>          it).  This enables you to make /usr/spool/mail drwxrwxrwt.  It is

>[This seems okay to me on the surface, but I'm told that it opens a large 
>security hole.]

No, it only opens a security hole if you use a broken (i.e. stock) /bin/mail
or bellmail to deliver the mail.  Procmail specifically takes countermeasures
to eliminate these potential security holes.

>        - If your system did not exhibit the !@#$%^&* POSIX semantics for
>          setgid(), procmail would have been able to switch back and forth

>Anyway, since it works, I guess that means that my system does *not* have
>the "!@#$%^&* POSIX semantics." But what if the next rev of the OS gets
>more POSIX-like?

My last encounter with AIX was about a year ago, so I don't know the exact
details anymore.  If I recall correctly AIX offers *only* POSIX semantics.
The POSIX semantics come into play if procmail is started with
root privileges *and* is sgid mail.  The root privileges interfere with
the sgid mail privileges and the sgid mail privileges are lost.  This
doesn't happen on a BSD system.

In your case, you are running procmail with recipient privileges, and
sgid mail.  This way there are no interfering root privileges, so the
sgid mail solution is perfectly all right (which actually is a solution
I forgot to include in the FAQ, which I'll make up for now).

>        - You could simply put the following at the end of your .procmailrc
>          file:

>                LOCKFILE                # removes any preexisting lockfile
>                LOG=`lockfile $DEFAULT$LOCKEXT`
>                TRAP="rm -f $DEFAULT$LOCKEXT"
>                        :0
>                        $DEFAULT

>locking? I have tried this and it works (yes, even after setting procmail
>back to a regular owner:group and no sgid), but I sure don't understand
>it. From watching the logfile, perhaps procmail tries only once to set the

This works because lockfile would be sgid mail on your system (and since
it is not suid root, this even works on pure POSIX systems).

>[What is "kernel locking?"

It uses a function call provided by the UNIX kernel to lock a file (an
advisory lock).

 Is the lock really there? If so, why doesn't 

As far as procmail is concerned, yes it is there.  The problem is that
the kernel might not propagate the lock across the net, or other mail
programs might not use the same kernel locking method.

>procmail just always use kernel locking instead of this lockfile confusion?]

Procmail v3.11 will contain a small fix that will supress any attempt
to use a lockfile in /usr/mail if:  /usr/mail is unwritable and at least one
kernel locking method is available.

>                :0:$HOME/.lockmail
>                $DEFAULT

>          You have to make sure that all other programs that update your
>          system mailbox will be using the same lockfile of course.

>might that be referring to? My user agent, I suppose. But I have no idea 
>what kind of locking it does. And I don't have any control over it in any 
>case. So I don't think I like this solution either.]

You could embed it in a shell script which performs appropriate locking,
but, admittedly, this is a bit kludgy.

>        - You can ignore the problem if you know that both your mail reader
>          and procmail use an overlapping kernel locking method.
>[In fact, ignoring it does seem to work as long as I'm willing to put up 
>with the delay caused by trying and failing to set the lock and finally 
>giving up. I'd prefer not to put up with that on efficiency grounds. 
>Plus, I still don't know what kernel locking is.]

Since a kernel locking method *is* being employed by procmail, you
could avoid the delay by simply putting the following at the
end of your .procmailrc file:

	:0
	$DEFAULT

>Right now, I'm running procmail setgid mail, and it seems to be working

In your case, the recommended solutions would be:
- Make procmail sgid mail, not suid root.
or
- Set the sticky bit on /usr/mail
or
- Simply ignore the problem and hope that your mail reader uses the
  same kernel locking method.

If you integrate procmail in sendmail, you have to be careful, since
procmail is then (or should be), by default, running setuid root, which
interferes again with the sgid mail privileges.

-- 
Sincerely,                                  [email-masked]
           Stephen R. van den Berg (AKA BuGless).

"My name is Smith, the P is not pronounced."