Phil Edwards <pedwards(_at_)valhalla(_dot_)cs(_dot_)wright(_dot_)edu> wrote:
individual .forward's on a per-user basis. Recently our mail admin
decided to implement sendmail 8.7.1 with the sendmail_restricted_shell
(smrsh) for increased security. Smrsh needs a list of the valid
programs to which users may pipe their mail, and procmail is included
in that list.
As Soren pointed out, this only is of marginal use. In fact, after
upgrading to sendmail 8.7.*, smrsh doesn't really increase the security
level anymore. The security hole in sendmail, smrsh was protecting
from, has since long been fixed.
It seems that the Bourne shell syntax cannot be read by smrsh. I've
done some experimenting with plain ol'
"|/usr/local/bin/procmail -f-#somebody"
If you're using sendmail 8.6.* or newer, the necessary and sufficient
.forward file would be:
"|exec /usr/local/bin/procmail"
Or, if you've been smrsh'd:
"|/usr/local/bin/procmail"
Nothing more, nothing less, and everything will work just perfectly.
and it seems to work, of course. My question is: what effect does
setting the internal field separator have on procmail? My understanding
is that the change to the IFS will only last for the rest of the parsing
of the .forward itself, and will not affect the child processes (i.e.,
procmail).
Your understanding is correct. The setting of IFS covers up a security
hole in older sendmails (8.6.* and newer don't need this anymore).
Procmail itself couldn't care less about the setting of the IFS.
I'm not too worried about missing the "|| exit 75" in the pipeline; we
only have a few people running procmail and they're all fairly
intelligent, they won't hose their rcfiles up and so forth. I think.
Actually, this was/is for NFS mounted procmail binaries that could
become temporarily lost (if the server crashed).
So: I know what the '&&' and '||' mean as far as syntax goes. I have
an opinion about what they do for procmail in this instance, but I'm
going to keep my mouth shut and ask for clarification from you. :-)
They're mostly there to get around silly limitations in (older) sendmail
implementations. Likewise for the '#someone' hack, which covers up
another bug in older sendmail implementations (8.6.* and newer need not
worry about it anymore).
--
Sincerely,
srb(_at_)cuci(_dot_)nl
Stephen R. van den Berg (AKA BuGless).
E Pluribus Unix.