Re: [Qemu-devel] [PATCH] -chroot and -su options.

[Rob Landley]

On Wednesday 05 March 2008 01:54:08 Edgar E. Iglesias wrote:
> On Wed, Mar 05, 2008 at 12:51:36AM -0600, Rob Landley wrote:
> > On Tuesday 04 March 2008 05:22:12 you wrote:
> > > On Mon, Mar 03, 2008 at 06:28:22PM -0600, Rob Landley wrote:
> > > > Quick and dirty patch to teach qemu application emulation how to
> > > > chroot (and drop privs), so you don't have to pollute a target
> > > > filesystem with host code, and/or figure out how to build qemu static
> > > > in order to run a dynamic binary.
> > >
> > > Hi Rob,
> > >
> > > Right, doing the chroot from within qemu avoids the issue with
> > > polluting the target/. Thanks for the example.
> > >
> > > The chroot approach still suffers from the need of initially having
> > > higher privileges. Personally, I still prefer the sysroot option and
> > > avoid that need but either way helps me.
> > >
> > > Best regards
> >
> > Which sysroot option?  (I may have missed a patch, I'm a month behind on
> > the list.  This is just something I've meant to submit for... about a
> > year, I think.)
> >
> > You can also teach a bunch of different qemu syscalls (open, unlink,
> > mmap, exec, fcntl, and 3 dozen others...) to append a prefix to its path,
> > and perhaps try to prevent them from playing games with symlinks or ".."
> > to break out of that subdir.  But that's a much, much, much more
> > extensive/intrusive patch.
>
> Hi,
>
> This is the updated example from my local git of how it could work, it only
> maps absolute paths. I don't think taking care of relative paths involves
> much more code but so far this behaviour has been enough for me. The sim
> simulators in GDB have a similar --sysroot option which I beleive behaves
> very similar (or equal).
>
> Please note that I'm not trying to jail in a program for security purposes,
> just for test and debug purposes.

Yeah, linux-user/path.c does seem to be trying to filter the paths.  (Does -L 
do more than just adjust the elf interpreter prefix?  The syscalls are 
wrapped in calls to path() which _could_ do something interesting, but 
doesn't.  (And freeing the string would probably require a static pointer so 
the next call frees the previous one.)

Even then, attempting to deal with things like symlinks that point to absolute 
paths would be quite a headache, and considering the default busybox install 
does exactly that, it's not exactly an unheard of corner case...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.