Hello,
I think this is ready for submission now. Please let me know how best to proceed.
Thanks
-Nick
https://github.com/bdraco/exim/commit/09792322d9224b0407783a19c2dd57fd1a8bbd52
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
>
