[systemd-devel] systemd-run checks path on host before running on container

[Zbigniew Jędrzejewski-Szmek]

On Sat, Nov 22, 2014 at 02:47:49PM +0100, David Herrmann wrote:
> Hi
> 
> On Fri, Nov 21, 2014 at 5:00 AM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > I was playing around with systemd-nspawn and systemd-run. The latter doesn't
> > seem to let me run a command that solely exists on the container.
> > simple way of reproducing: drop a file foo into the container, then on the
> > host run
> >
> >     systemd-run -M mycontainer /path/to/foo
> >
> > I expected this to run foo on the container. It does, but checks for the
> > command to exist locally first and fails. A simple touch /path/to/foo; chmod
> > +x $_ is sufficient to bypass that check, but that feels somewhat odd.
I pushed a partial fix which makes find_binary() ignore errors for
non-local absolute paths. Something which checks the path remotely
might be nicer, but I'm not sure if it's worth the hassle.

Zbyszek

> > run.c calls find_binary() [1] which doesn't take the container argument into
> > account. So it does what the code tells it to do, I'm just not sure
> > whether it is a bug or intended behaviour and I misunderstood something.
> 
> Not a bug in particular, but definitely odd behavior. If you use -M
> with systemd-run, it's clear that the passed binary has to reside in
> the container, otherwise, the newly created transient unit inside of
> the container will not find the binary. So yeah, we should make it
> work.
> 
> I see 2 "easy" solutions for this:
> 
> 1) If the binary is given as full path but we cannot find it, print a
> warning but proceed.
> 
> 2) If "-M" is given, read "ROOT=" from /run/systemd/machine/* (similar
> to our container_get_leader() helper in src/shared/util.c). Then
> prepend this as prefix to any absolute path.
> 
> The find_binary() helper also searches $PATH if the given binary is
> not a path itself. I'm not sure how to implement that for containers.
> We cannot easily get the $PATH variable of the container (we'd have to
> open a new session). Furthermore, it sounds wrong to read PATH from
> something outside the context of the caller (similarly, we don't want
> hacks like prepending ROOT to the current PATH of the caller).
> I'd say we only support find_binary() if -M is not given. Otherwise,
> we go with option 2) and try to resolve the whole path. And, maybe, if
> we cannot resolve the path (like ROOT= is not given), we print a
> warning if -M was passed and still proceed.
> 
> CC'ing Lennart, he might have more insight.