Discussion:
procmail - Enforcing stricter permissions
System Maintenence
1997-04-03 05:28:39 UTC
Permalink
Greetings.

I am currently maintaining several linux servers with full internet
services, and suddenly, quite without warning, one of them (2.0.0 kernel -
slackware dist.) started bouncing back mail with errors like -

procmail: Enforcing stricter permissions on "/var/spool/mail/ntsnwa"
procmail: Lock failure on "/var/spool/mail/ntsnwa.lock"
procmail: Error while writing to "/var/spool/mail/ntsnwa"
550 <***@dreamland.dicksonstreet.com>... Can't create output: Error 0

It would seem that this would either entail a bad permission on a file in
/var/spool/mail or sendmail (or procmail) is not running with the correct
permissions (as root?)

Here is an example entry from /var/spool/mail -

-rw-rw---- 1 ntsnwa mail 0 Apr 2 13:24 ntsnwa


^^^^^^^^^^ is this not correct? I have another box on the same network and
they 'appear' the same.

Typing 'procmail -v' reveals -

procmail v3.10 1994/10/31 written and created by Stephen R. van den Berg
***@pool.informatik.rwth-aachen.de

<snip --- for your convenience --- snip>

Locking strategies: dotlocking, fcntl(), lockf()
Default rcfile: $HOME/.procmailrc
System mailbox: /var/spool/mail/$LOGNAME


Telnet'ing in yields -
220 dreamland.dicksonstreet.com ESMTP Sendmail 8.8.3/8.8.3; Wed,2 Apr1997 21:0


What can I do to fix this? I have searched usenet and found a similar
question w/o a reply yet. Can I expect this from my other machine running
same versions? Why have a never seen this before on the other
configurations I have run?

HELP!

Jeff
Philip Guenther
1997-04-03 07:05:21 UTC
Permalink
Post by System Maintenence
I am currently maintaining several linux servers with full internet
services, and suddenly, quite without warning, one of them (2.0.0 kernel -
slackware dist.) started bouncing back mail with errors like -
procmail: Enforcing stricter permissions on "/var/spool/mail/ntsnwa"
procmail: Lock failure on "/var/spool/mail/ntsnwa.lock"
procmail: Error while writing to "/var/spool/mail/ntsnwa"
It would seem that this would either entail a bad permission on a file in
/var/spool/mail or sendmail (or procmail) is not running with the correct
permissions (as root?)
What are the permissions of /var/spool/mail and the procmail binary?
Also, is /var/spool/mail local? (If it isn't then that's probably part
of the problem. Delivering mail to an NFS mounted partition is
generally a bad idea, though there are exceptions.) As a wild guess I
would say that you are NFS mounting /var/spool/mail and someone told
the server to stop giving root privileges to client machines. If this
is the case then I would suggest you change your sendmail setup so that
all mail delivery takes place on the server, with the NFS clients
either using a "nullclient" configuration (forward all mail to the
server) or a mailhub configuration (forward local mail to the server,
deliver offsite mail directly)... unless you have a good reason for
doing otherwise. Like every other decision in system administration,
there are expections.

BTW: if you do choose to deliver to an NFS mounted partition, keep in
mind that Linux *does not support* kernel locking (fcntl/lockf/flock)
across NFS, so you *MUST* be sure that dotlocking works. Seeing "lock
failure" messages would mean that you're open to corrupted mailboxes.
Post by System Maintenence
Here is an example entry from /var/spool/mail -
-rw-rw---- 1 ntsnwa mail 0 Apr 2 13:24 ntsnwa
^^^^^^^^^^ is this not correct? I have another box on the same network and
they 'appear' the same.
Whether the above permission are correct depends on what permissions
procmail runs with. If procmail is setuid root then the above are
almost certainly wrong.

...
Post by System Maintenence
Telnet'ing in yields -
220 dreamland.dicksonstreet.com ESMTP Sendmail 8.8.3/8.8.3; Wed,2 Apr1997 21:0
Hmm, I suggest you upgrade to 8.8.5, or if you haven't already, at the
very least remove the '9' flag from any mailers that have it (local and
prog have it by default), as there's a remotely exploitable security
hole in it's implementation.


Philip Guenther

Loading...