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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
