Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

Transport command lookup, splitting argv[0] after expansion

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


g at yom

Sep 30, 2009, 2:32 AM

Post #1 of 5 (780 views)
Permalink
Transport command lookup, splitting argv[0] after expansion

Hi list,


I'm trying to setup a pipe transport with a dbm lookup of its command.
Apparently, it only works without args because it doesn't split args
after lookup. Here's an example :


1 - Create a dbm with a key containing a command with 1 or more args :
--
$ perl -e 'dbmopen(my %db, "/tmp/test.db", 0666); $db{test} = "/bin/echo test"; dbmclose(%db);'


2 - Configure a simple transport looking up this command :
--
test_delivery:
driver = pipe
command = ${lookup{test}dbmnz{/tmp/test.db}}


3 - Test it (this is Exim 4.43) :
--
>>>>>>>>>>>>>>>> Local deliveries >>>>>>>>>>>>>>>>
--------> test [at] test <--------
locking /var/spool/exim/db/retry.lockfile
locked /var/spool/exim/db/retry.lockfile
opened hints database /var/spool/exim/db/retry: flags=0
dbfn_read: key=T:test [at] test
no retry record exists
search_tidyup called
changed uid/gid: local delivery to test <test [at] test> transport=test_t
uid=8 gid=12 pid=17434
auxiliary group list: <none>
home=NULL current=/
set_process_info: 17434 delivering 1MsvKS-0004X2-CT to test using test_t
test_t transport entered
direct command:
argv[0] = ${lookup{test}dbmnz{/tmp/test.db}}
search_open: dbmnz "/tmp/test.db"
search_find: file="/tmp/test.db"
key="test" partial=-1 affix=NULL starflags=0
LRU list:
2/tmp/test.db
End
internal_search_find: file="/tmp/test.db"
type=dbmnz key="test"
file lookup required for test
in /tmp/test.db
lookup yielded: /bin/echo test
direct command after expansion:
argv[0] = /bin/echo test
set_process_info: 17436 reading output from |${lookup{test}dbmnz{/tmp/test.db}}
Writing message to pipe
writing data block fd=9 size=54 timeout=3600
writing error 32: Broken pipe
transport error EPIPE ignored
test_t transport yielded 2
search_tidyup called
test_t transport returned FAIL for test [at] test
post-process test [at] test (2)
LOG: MAIN
** test [at] test R=test_r T=test_t: Child process of test_t transport returned 127 (could mean unable to exec or command does not exist) from command: "/bin/echo test"
>>>>>>>>>>>>>>>> deliveries are done >>>>>>>>>>>>>>>>


As you can see, argv[0] contains "/bin/echo test". I'm not a programming
expert but according to execve(2), that's bad.

Is this a normal behaviour ? If so, how can I ensure that exim will
correctly split the command and its args before calling execve() ?


Thanks,

--
Guillaume

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


dean.brooks at iglou

Sep 30, 2009, 7:06 AM

Post #2 of 5 (737 views)
Permalink
Re: Transport command lookup, splitting argv[0] after expansion [In reply to]

On Wed, Sep 30, 2009 at 11:32:06AM +0200, Guillaume Blairon wrote:
> I'm trying to setup a pipe transport with a dbm lookup of its command.
> Apparently, it only works without args because it doesn't split args
> after lookup. Here's an example :
>
> 1 - Create a dbm with a key containing a command with 1 or more args :
> --
> $ perl -e 'dbmopen(my %db, "/tmp/test.db", 0666); $db{test} = "/bin/echo test"; dbmclose(%db);'
>
> 2 - Configure a simple transport looking up this command :
> --
> test_delivery:
> driver = pipe
> command = ${lookup{test}dbmnz{/tmp/test.db}}

The part of the Exim manual that discusses this issue, and the
provided workaround, is in section 29.3:

] The expansion is done in this way, argument by argument, so that the
] number of arguments cannot be changed as a result of expansion, and
] quotes or backslashes in inserted variables do not interact with
] external quoting. However, this leads to problems if you want to
] generate multiple arguments (or the command name plus arguments) from
] a single expansion. In this situation, the simplest solution is to use
] a shell. For example:
]
] command = /bin/sh -c ${lookup{$local_part}lsearch{/some/file}}

It looks like this should work based on my reading of the docs, so I
would try using:

test_delivery:
driver = pipe
command = /bin/sh -c ${lookup{test}dbmnz{/tmp/test.db}}

--
Dean Brooks
dean [at] iglou

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users-20081202 at djce

Sep 30, 2009, 1:31 PM

Post #3 of 5 (752 views)
Permalink
Re: Transport command lookup, splitting argv[0] after expansion [In reply to]

On Wed, Sep 30, 2009 at 11:32:06AM +0200, Guillaume Blairon wrote:
> test_delivery:
> driver = pipe
> command = ${lookup{test}dbmnz{/tmp/test.db}}
>
> As you can see, argv[0] contains "/bin/echo test". I'm not a programming
> expert but according to execve(2), that's bad.
>
> Is this a normal behaviour ? If so, how can I ensure that exim will
> correctly split the command and its args before calling execve() ?

The 4.68 spec says: "The command is split up into separate arguments by Exim,
and each argument is separately expanded, as described in section 29.3". i.e.
the split into argv[0] + arguments happens /before/ expansion, not afterwards.
So yes, this behaviour is as per spec, and therefore normal.

Maybe you'd prefer:
command = sh -c ${lookup{test}dbmnz{/tmp/test.db}}
which is three arguments: "sh", "-c", and then the result of the expansion.

Insert usual security lecture here, which may or may not be appropriate
depending on your application.

Regards,

--
Dave Evans
http://djce.org.uk/
http://djce.org.uk/pgpkey
Attachments: signature.asc (0.19 KB)


exim-users at spodhuis

Oct 1, 2009, 12:55 AM

Post #4 of 5 (735 views)
Permalink
Re: Transport command lookup, splitting argv[0] after expansion [In reply to]

On 2009-09-30 at 11:32 +0200, Guillaume Blairon wrote:
> 1 - Create a dbm with a key containing a command with 1 or more args :
> --
> $ perl -e 'dbmopen(my %db, "/tmp/test.db", 0666); $db{test} = "/bin/echo test"; dbmclose(%db);'
>
>
> 2 - Configure a simple transport looking up this command :
> --
> test_delivery:
> driver = pipe
> command = ${lookup{test}dbmnz{/tmp/test.db}}

> lookup yielded: /bin/echo test
> direct command after expansion:
> argv[0] = /bin/echo test

> As you can see, argv[0] contains "/bin/echo test". I'm not a programming
> expert but according to execve(2), that's bad.
>
> Is this a normal behaviour ? If so, how can I ensure that exim will
> correctly split the command and its args before calling execve() ?

You can read the documentation on the pipe transport to see what options
are available to tune its behaviour and what suggestions are made.

Eg, "29.3 How the command is run" will show you how to use { /bin/sh -c }
to work around this.

Or you might play with the "use_shell" option, to see how that affects
the behaviour.

The default behaviour assumes that the command is well known ahead of
time and that data can be arbitrary and untrusted, so shouldn't be split
on whitespace. By default, a shell is not used to invoke the command,
but you can manually choose to use a shell.

Regards,
-Phil

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


g at yom

Oct 1, 2009, 2:34 AM

Post #5 of 5 (742 views)
Permalink
Re: Transport command lookup, splitting argv[0] after expansion [In reply to]

On 01/10 - 00:55:39, Phil Pennock wrote:
> You can read the documentation on the pipe transport to see what options
> are available to tune its behaviour and what suggestions are made.

Well, guess I missed that part of the documentation.. thanks for the
explanations !

--
Guillaume

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.