Philip> Hmm. I guess I ought to implement an option on the pipe
Philip> transport that says "use a shell", though I'm not too happy
Philip> about that. How about an option that says "ignore this string
Philip> at the start of the command"? Then you could make it ignore
Philip> "IFS=' ' && exec". No, that won't help because of the "||
Philip> exit 75" on the end. Perhaps some kind of pattern match? Just
Philip> thinking random thoughts here...
I would rather create another transport that mail adminstrators use
instead of the current pipe transport. A possible thought is to
create the equivalent of the sendmail "prog" mailer: a transport that
always runs <program + args> <pipe-expansion> (sorry if I don't have
the terminology right). <program + args> would be determined by a
transport option, defaulting to "sh -c". Making this both a separate
transport and making the program configurable will also allow people
to use something like "smrsh" (ugh) and also not force people to do
the extra fork.
Philip> Apart from the syntax and security problems, it is, of
Philip> course, more efficient not to use a shell in general, as you
Philip> save a fork() operation (unless you use exec, as above - many
Philip> users piping to random scripts wouldn't think of that).
You save the shell invocation, too.
Philip> The point about it not being a security issue because the
Philip> user can specify a shell anyway is true, but idea was that it
Philip> would avoid more accidents if those that wanted a shell had
Philip> to ask for it explicitly.
Well, what kind of accidents? Not that I don't think the current
mechanism is bad.
--
David Blacka Software Engineer Directory Services/
davidb@??? Network Solutions, Inc. RWhois Development
