At 13:29 2002-10-07 -0500, Joe Leske wrote:
I'm a procmail newbie and am just about ready to deploy a procmail recipe in
everyone's home folder.
Unfortunatley, everyone here is in the dark as to what that recipe
contains, what version of Procmail you're running, what OS you're running,
and what type of locking strategy your system supports, as well as what
procmail itself has been compiled for. These are all important things when
trying to track down problems.
3.11pre7 (which is, by internet terms, ANCIENT - over five years old),
resolved some issues with "fallback" locking strategies. Hopefully, you're
running something newer than that, but since you don't mention version,
what do we know?
procmail: Bypassed locking "/var/spool/mail/username.lock"
This is called "dotlocking". It requires that the user (or their group)
which the process is running as have WRITE perms in the directory in
question. I can't help but suspect that your users don't have perms to
indiscriminatley create files in the mail spool dir. What do you think?
<http://www.rosat.mpe-garching.mpg.de/mailing-lists/procmail/2001-06/msg00093.html>
<http://www.rosat.mpe-garching.mpg.de/mailing-lists/procmail/1997-07/msg00590.html>
<http://www.rosat.mpe-garching.mpg.de/mailing-lists/procmail/1997-04/msg00555.html>
The log file then shows this mailbox file to be assigned as LASTFOLDER,
opens it, and uses a kernel lock.
Don't take this wrong, but if you're a self-admitted procmail newbie, it'd
really help if rather than providing a summary of your interpretation of
the logfile, you excerpted that section of the VERBOSE logfile and
presented it here for peer review, perhaps adding what your interpretation
of it is looking for confirmation.
An auto mechanic can only _guess_ as to what your problem is if you come in
saying you hear "some noise" without identifying the specific make and
model of your car, and even with that info, without having the car to check
themselves, they're making a number of assumptions on what it might
be. Better to drive it in and have the mechanic take a look under the hood
themselves.
If it's a big script, post it to a webpage someplace and refer to
that. Better yet, reduce it down to a short recipe that demonstrates the
problem.
>From what I've read, it seems that procmail requires permissions to the
/var/spool/mail/username file before it can lock it.
Uhm, yea. Depends on the locking strategy as well. Dotlocking doesn't
make loads of sense for the mail spool dir. Works fine for regular files
in the users' own dirs though. The user owns their own mailspool file -
that's fine -- but they DON'T own the DIR, and depending upon your config,
probably don't have write perms there, beyond their mailspool file which
was basically created by _root_ and assigned to that user.
'procmail -v' would tell you a lot:
wargames:~$ procmail -v
procmail v3.22 2001/09/10
[snip]
Locking strategies: dotlocking, fcntl(), lockf(), flock()
Default rcfile: $HOME/.procmailrc
Your system mailbox: /var/spool/mail/(username)
(that's from one of my systems - your results are likely different)
I use a .procmailrc file in my home folder and it's invoked over the
.forward file.
Then providing the .forward contents could be, uh, useful.
You might want to check out the procdiag script linked from my disclaimer -
it should be able to collect up most of the important configuration tidbits.
I want to know how to give procmail the permissions to lock this file
without giving it too much control in case a hacker exploits it.
You stand a greater chance of a bad script becoming exploitable than of
procmail itself being exploited.
If you lock a mailspool file, you need to lock it using the same mechanisms
which the system LDA and POP/IMAP normally would, because they're the
processes you need to worry about manipulating the file while you're
writing to it.
PS - The place where mail goes to if all conditions in the recipe match is a
file with the location - /home/viruses. I had to make this file world
writable to let procmail lock it and dump messages into it. Could this be a
problem?
Suggestion: define the directory as a dir which user 'x' owns and can write
to (assuming you're testing as 'x'). When you've got your script sorted,
change the dir to be owned by nobody or some virus administration user or
whatever, and put the script in /etc/procmailrcs, invoked from an INCLUDERC
in /etc/procmailrc (note no leading dot). If procmail is your LDA (while
that's the best way to run it generally, it also happens to be the optimal
way to do exactly what you seem to be doing - a global virus filter). When
procmail is running the /etc/procmailrc file, it is running as whatever
user your MTA is invoked as (often root, seeing as it needs to be able to
assume the identity of individual users at will to deliver on their
behalf), which would then allow it to write to a directory that user could
write to. When you invoke procmail from a .forward, the /etc/procmailrc
isn't part of the picture, and procmail is being initialized under that
users' own UID and cannot "gain" additional privledges (which is also the
case when procmail-as-LDA switches from processing the /etc/procmailrc to
the users' .procmailrc).
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail