Philip Guenther answered Roderick Schertler,
| > If you put a variable assignment on the command line, procmail will give
| > up it's setuid and setgid privileges.
Roderick continued,
| Thanks, I didn't realize that.
|
| This isn't the (only) cause here, though. I created a ~/.procmailrc
| which contains just
|
| LOGFILE = procmail.log
| VERBOSE = on
|
| I invoked it as "./procmail < message" and I got the same results:
|
| procmail: [12334] Fri Apr 18 18:12:31 1997
| procmail: Bypassed locking "/var/mail/roderick.lock"
| [...]
Doesn't procmail also give up its setuid and setgid privileges as soon as it
reads a user's rcfile? (I've no experience with procmail as the MDA, only
with calling it from .forward or from a shell prompt, and it's always my own
compilation and never setuid root nor setgid mail, so I don't know for sure.)
I think Roderick is in the same situation as many of the rest of us. If
his sysadmins cannot be cajoled or blackmailed into chmodding the mail spool
to 1777, then he'll have to choose either (1) naming a lockfile somewhere
under his $HOME for saves to $DEFAULT (and praying that no other utility
tries to get a lock on /var/mail/roderick at the same time as procmail) or
(2) forswearing /var/mail/roderick and assigning DEFAULT a value under his
$HOME, where the folder and the .lock file will both be creatable and
removable under his permissions as a user.