"John D. Hardin" <jhardin(_at_)wolfenet(_dot_)com> writes:
I've gotten the following problem report from an admin running my
perl-based MIME sanitizer: whenever mail to one of the wheel group users
is received, perl complains about being run setuid.
Can you have the reporting admin answer the following questions?
What are the permissions and ownerships (user and group) of the mail
spool directory and the procmail binary, and how is procmail being
called? (If it's being called as the local mailer from sendmail, what
is the output of
sendmail -odi -d11.2 -f root some_group_wheel_user < /dev/null
?) Finally, what is the output of
grep gid /path/to/compiled/procmail/sources/autoconf.h
?
As a possible quick blind-guess solution, if the spool directory is
world writable then make procmail *not* setgid. That _might_ work.
Here's the /etc/procmailrc:
SHELL=/bin/ksh
DROPPRIVS=YES
LOGFILE=$HOME/procmail.log
PATH="/usr/local/bin;/usr/bin;$PATH"
This isn't causing the problem with perl, but those semicolons should be
colons.
LOG=`id`
INCLUDERC=/etc/procmail/html-trap.procmail
LOGFILE=/dev/null
And here's the first bit of the log, neatened up a bit:
uid=968(cyber) gid=0(wheel) egid=100(user) groups=100(user), 0(wheel),
6(uucp), 20(staff), 101(shell)
Sanitizing MIME attachment headers in "test" from David Monk
<cyber(_at_)ns(_dot_)vantek(_dot_)net> to cyber
No -e allowed in setuid scripts.
procmail: Program failure (255) of " perl -p -e ' #\
The gid/egid discrepancy is triggering the setuid warning. Shouldn't the
gid also be 100 after DROPPRIVS?
Yes, assuming the platform has reasonable saved group id semantics.
(Hint: most screw this up. Even BSD 4.4 and POSIX miffed this.)
Procmail may need to switch gids in order to dotlock the mailspool.
Philip Guenther