At 19:49 2006-11-30 +0000, CosmicPerl.com Support wrote:
Yes, I've already been logging with
VERBOSE=yes
# For debugging uncomment this line
LOGABSTRACT=all
# Tell procmail where to put the log file
LOGFILE=/var/log/procmail.log
didn't see these in the content you posted earlier. Is there more to the
rcfile?
Like I said before, the message IS being written to almost-certainly-spam
and probably-spam. It's just ALSO being written to the users mailbox as
well.
which implies there's something fubar about your LDA setup.
The only wierd thing I noticed in the log was that it never showed any
user apart from root.
(which is significant as it relates to root being _able_ to write to the
other files)
So it would have lines of either:-
procmail: Opening "/var/mail/root"
procmail: Opening "probably-spam"
or
procmail: Opening "/dev/null"
Never any other users. Does that indicate the problem? I just guessed that
SendMails virtusertable was handling the usernames and final mailbox
delivery.
These final deliveries are _LOCAL_ users, right? If you have some VPOP
config or remote mail, procmail shouldn't be part of the picture.
Set pwd? I added the line for MAILDIR as before it was making a
probably-spam file in /var/spool/mqueue
uh, er, uhm....
How are you invoking procmail? From within a sendmail rule, in an alias,
or as the LDA?
I can't see why procmail would fire up with mqueue as the cwd (typo on my
part above).
Owner for probably-spam is user and group probably-spam. It's till being
written to without errors.
world writeable? What users are writing?
I'm guessing from this that as the probably spam file is being written to
procmail must be running as root. Is this a security hole, if so how big and
what can I do to stop it???
well, if it's delivering _for_ root at the time, it's running as root.
in the global, /etc/procmailrc file, the DROPPRIVS=YES is there to shed
root privledges and assume the user identity the mail is being delivered
for. USERS shouldn't be able to manipulate the /etc/procmailrc. having
elevated privleges during mail processing is a useful thing - it allows you
to write to files and do things that perhaps the individual user
can't. When procmail transitions to the user procmailrc,
$HOME/.procmailrc, it automatically sheds the elevated privleges and
assumes the user identity, so contents of THAT procmailrc file are not a
security risk.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail