[Libguestfs] [PATCH] daemon: always provide stdin when running chroot commands (RHBZ#1280029)

[Mateusz Guzik]

On Tue, Dec 01, 2015 at 04:58:11PM +0000, Richard W.M. Jones wrote:
> On Tue, Dec 01, 2015 at 03:59:56PM +0100, Mateusz Guzik wrote:
> > CHROOT_IN/OUT around commandvf are definitely problematic. chroot should be
> > done in the child, which also removes the need to chroot out in the
> > parent.
> 
> The CHROOT_IN/OUT business does need to be rewritten.  Every
> instance where we currently do something like:
> 
>   CHROOT_IN;
>   r = stat (fd, &statbuf);
>   CHROOT_OUT
> 

Ouch. Fortunately commandvf change should be easy.

> [https://github.com/libguestfs/libguestfs/blob/master/daemon/stat.c#L93-L95]
> 
> should instead be forking a subprocess, chrooting in the subprocess,
> and doing the system call in the subprocess.
> 
> The problem which makes it not so easy is that instead of using a nice
> local variable, we would have to pass back the result from a
> subprocess to the parent process (the pair (r, statbuf) in the above
> example).
> 
> So that means .. a pipe, and serializing the result down the pipe.
> 
> The good news is that since this all runs on the same machine in the
> same compiled program, it's quite acceptable to dump a C struct into
> the pipe.
> 
> But it's still a lot of work .. patches welcome of course.
> 

This looks very problematic.

CHROOT_OUT is mere chroot ("."), which suggests that that cwd for
virt-builder is "/". This means anything using aforementioned construct
has to use absolute paths, otherwise it looks names up against the real
"/". For current code it would make sense to somewhow check if all
passed paths are absolute (if not by code inspection, one can try to
cook up a systemtap script to verify such behaviour in-between chroots).

As for a solution, forking off a process which chroots is definitely on
the right track. However, I would argue what's really needed here is the
following: at the start, a container is created, the child gets in. Execs,
file system operations, just about everything has to be a request sent
to the child over e.g. a unix socket, but pipes could work too.

Filesystems in the container would not be fully populated (see: /dev/mem
& friends), but only have 'container-friendly' files.

That's definitely a lot of work and I'm not up to the task.

Regardless, commandvf vs chroot usage can be improved without said
significant work.

-- 
Mateusz Guzik