Hi Phil,
I worked up something along those lines. I can't say I'm in _love_ with the results, however I do think the behavior is correct.
I pushed up a 'rough draft' (I will clean it up some more if this looks good on screen)
https://github.com/bdraco/exim/commit/e7edc8fa00a56c3548fdb3702402b927ab230e9b
I also need to do some testing to make sure It doesn't explode when given 65, 1 or 0 arguments
Thanks
-Nick
On Mar 31, 2013, at 12:47 AM, Phil Pennock <pdp@???> wrote:
> On 2013-03-31 at 00:20 -1000, J. Nick Koston wrote:
>> I was actually able to get the force_command approach working after
>> doing some more digging into exim guts to understand how things work a
>> bit better. Its a much more simple approach.
>
> *phew* I wasn't crazy to suggest it then. :)
>
>> https://github.com/bdraco/exim/commit/force_command
>>
>> Please let me know what else you would like me to do to prepare this.
>
> As things stand, I think you've invalidated our security guarantees
> about argument-by-argument expansion. Also, you do the expansion before
> $1 and friends are set up.
>
> I suspect that the cleaner solution is to give a 'flags' parameter to
> the `set_up_shell_command()` function call, then if force_command is
> set, include a FLAG_VALUE or'd into the flags parameter which says to
> treat $address_pipe specially, needing to be split apart into multiple
> parameters.
>
> This way, expansion occurs in the normal place, and you have one
> special-case piece of logic, which can be documented in "29.3 How the
> command is run" too, noting that if force_command is set and the command
> came from a router, then command is evaluated and $address_pipe is split
> up and is *not* held to one option, like everything else.
>
> This minimises the impact, avoids expanding the string in different
> places, with different variables already set up, and avoids quotes and
> backslashes in data resulting from expansion ending up creating new
> parameters.
>
> Regards,
> -Phil
>
