Re: [exim-dev] use_wrapper patch

Top Page
Delete this message
Reply to this message
Author: J. Nick Koston
Date:  
To: Phil Pennock
CC: exim-dev
Subject: Re: [exim-dev] use_wrapper patch
Hi Phil,

I started working down that path, however once it does the expansion, everything ends up in one argument (argv[1])

distributed_address_pipe transport entered
direct command:
argv[0] = /usr/local/cpanel/bin/remote_mail_exec
argv[1] = ${substr{1}{$address_pipe}}
direct command after expansion:
argv[0] = /usr/local/cpanel/bin/remote_mail_exec
argv[1] = /usr/local/cpanel/bin/remote_mail_exec_test -p -d

From transport.c

On line 2026 its going to just push everything into one argument.

It looks like $pipe_addresses is handled as a special case. I could just make $address_pipe a special case (just sounds icky though) and strip of the leading |, however I'm not familiar with code to fully understand the implications (it starts to make the use_wrapper idea look better).

Would you be so kind as to provide some guidance?

Thanks
-Nick

1979     /* Handle special fudge for passing an address list */
1980 
1981     if (addr != NULL &&
1982         (Ustrcmp(argv[i], "$pipe_addresses") == 0 ||
1983          Ustrcmp(argv[i], "${pipe_addresses}") == 0))
1984       {
1985       int additional;
1986 
1987       if (argcount + address_count - 1 > max_args)
1988         {
1989         addr->transport_return = FAIL;
1990         addr->message = string_sprintf("Too many arguments to command \"%s\" "
1991           "in %s", cmd, etext);
1992         return FALSE;
1993         }
1994 
1995       additional = address_count - 1;
1996       if (additional > 0)
1997         memmove(argv + i + 1 + additional, argv + i + 1,
1998           (argcount - i)*sizeof(uschar *));
1999 
2000       for (ad = addr; ad != NULL; ad = ad->next) argv[i++] = ad->address;
2001       i--;
2002       }
2003 
2004     /* Handle normal expansion string */
2005 
2006     else
2007       {
2008       uschar *expanded_arg;
2009       enable_dollar_recipients = allow_dollar_recipients;
2010       expanded_arg = expand_string(argv[i]);
2011       enable_dollar_recipients = FALSE;
2012 
2013       if (expanded_arg == NULL)
2014         {
2015         uschar *msg = string_sprintf("Expansion of \"%s\" "
2016           "from command \"%s\" in %s failed: %s",
2017           argv[i], cmd, etext, expand_string_message);
2018         if (addr != NULL)
2019           {
2020           addr->transport_return = expand_failed;
2021           addr->message = msg;
2022           }
2023         else *errptr = msg;
2024         return FALSE;
2025         }
2026       argv[i] = expanded_arg;
2027       }
2028     }




On Mar 29, 2013, at 9:35 PM, Phil Pennock <pdp@???> wrote:

> On 2013-03-29 at 17:19 -1000, J. Nick Koston wrote:
>> Thanks for the quick response. Supporting arbitrary commands being forcibly
>> wrapped when they come from a router is exactly what we are needing to accomplish.
>>
>> I would be happy to attempt to cook up a patch to implement "override_router" and push it to github, or wherever is best?
>
> Posting here is good. If you're happiest with a GitHub PR, I can make
> that work, but it's more of an exception -- we take changes as
> available, rather than _insisting_ people do things our way. But we
> _prefer_ exim-dev.
>
> Er, there's a recent example to the contrary, but that's because Todd
> has a mega-branch to merge, with many patches, and we're trying out
> GitHub's tools as a way to manage it. Maybe. It's not
> precedent-setting, though. (I think?)
>
>>> override_router
>>> command = prefix -args -- $address_pipe
>>
>> Thats exactly what we need. The commands are coming in from filter filer.
>
> It would need testing to be sure, but this should just be a matter of
> changing src/transports/pipe.{h,c} to add a boolean option and then in
> pipe_transport_entry() around line 570 add in support for this new
> boolean.
>
> It looks as though $address_pipe includes the leading "|" symbol, but
> I'm not 100% on this from looking at the code; is that likely to be an
> issue?
>
> -Phil
>