>>>>> "Pete" == Pete Ashdown <pashdown@???> writes:
Pete> I realize the insecurity of /bin/sh, but I have local users who
Pete> use the procmail line:
Pete> "|IFS=' ' && exec /usr/local/bin/procmail -f- || exit 75"
Pete> I read through the archives and Philip essentially said "change
Pete> the procmail line". This isn't an option here.
The reason why this line works in sendmail is that sendmail uses
/bin/sh to do the pipe delivery, whereas exim exec()s the program
directly.
I don't think that there is a solution that won't get your hands
dirty, here, unless Phillip were to do the thing for you. Basically,
your solution boils down to these possibilities (as I see it, anyway):
1. Change the procmail invocation. All the IFS=' ' etc crap just
isn't necessary. Since this isn't an option for you...
2. Modify src/transports/pipe.c to change the mailer argv to be
"/bin/sh" "sh" "-c" <old argv>. I'm not sure how tricky this would
really be. It looks like just before the call to "child_open"
(which is the culprit), munge the argv, and go.
3. Create a new pipe transport that does #2, or is configurable to do
this. In fact, it probably wouldn't be that wrong to define a
transport to do program delivery to a particular program anyway,
sort of like an exim version of the sendmail Mmailer garbage.
4. Change the execve call in child_open. This is probably
unsatisfactory, though.
I don't security is really an issue here. Invoking "sh -c" versus the
program directly seems sort of irrelevant, because a user could just
have a .forward like
|sh -c "stuff"
--
David Blacka Software Engineer Directory Services/
davidb@??? Network Solutions, Inc. RWhois Development
