Ricky Roque <ricky(_at_)dynanet(_dot_)ad(_dot_)jp> writes:
...
Also I noticed that procmail that runs long take on a
uid of 0, while procmail that takes longer time, take
on the senders uid.
A snapshot of the host's procmail processes are shown:
The first 4 take long time to process. The fifth finished
immediately.
ps axj | grep proc
PPID PID PGID SID TT TPGID STAT UID TIME COMMAND
85 100 100 100 ? -1 ROE 0 21:00 procmail -f
tutui(_at_)cac(_dot_)co(_dot_)j
p
600 602 602 602 ? -1 ROE 0 7:46 procmail -f
hasebe(_at_)hyperme
di
720 721 721 721 ? -1 ROE 0 6:40 procmail -f
waka(_at_)CosmoWork
s.
1089 1090 1090 1090 ? -1 ROE 0 3:42 procmail -f
fujiosh(_at_)sumito
mo
1545 1546 1546 1546 ? -1 SOE 5483 0:00 procmail -f MAILER-DAEMON@
ur
I've tried to tweak with the local mailers flag set on sendmail.cf.
The recommended is : Mlocal, P=/usr/local/bin/procmail,
F=lsSDFMhPfn, S=10, R=20/0, A=procmail -a $h -d $u, M=2000000.
I've tried to remove F=S flag, but same thing happens,(still run with
uid 0).
...
I'm desperate. Please help.
My machine: SunOS ns0 4.1.4 2 sun4m
Sendmail sendmail-8.7
procmail procmail-3.10
If you're using sendmail 8.7, then you should consider upgrading to
sendmail 8.8.5 (versions starting with 8.7 up to 8.8.4 have a security
hole which can give _remote_ users *root* access). I would not be
surprised if procmail is going runaway because sendmail is passing it a
bogus file descriptor. You can check this by using lsof (LiSt Open
Files) on one of those runaway procmail to see where it's getting it's
data. If fd 0 isn't a pipe back to sendmail, then this is your problem
and you *must* upgrade sendmail.
Part of the reason I think the above likely is that procmail reads in the
entire message while it's still root.
You should also consider upgrading to procmail 3.11pre4, as it fixed
several known bugs in 3.10 (though none that should be making it go
runaway).
Whether or not you upgrade, you should consider using the m4 config file
generators to create a new config file, as then you can just say
FEATURE(local_procmail)
and it'll do the changing of the local mailer for you. The reason you want
to do that, is that the "recommended" entry you show is almost surely
wrong. If you change the local mailer to procmail by hand, the only things
that change are the following directives:
P=/usr/local/bin/procmail
A=procmail -a $h -d $u
F= add the 'S', 'f' and 'h' flags, remove the 'm' and 'r' flags.
The 'S' and 'R' directives should be unchanged from what they were before.