Date: Fri, 14 Mar 2008 15:08:57 +0100
From: "Edgar E. Iglesias" <edgar.iglesias@axis.com>
Subject: Re: [Qemu-devel] [PATCH] -chroot and -su options.
Message-ID: <20080314140857.GE17978@edgar.se.axis.com>
References: <200803031828.22657.rob@landley.net>
	<200803050051.36813.rob@landley.net>
	<20080305075408.GB16728@edgar.se.axis.com>
	<200803060047.13113.rob@landley.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200803060047.13113.rob@landley.net>
Reply-To: qemu-devel@nongnu.org
To: Rob Landley <rob@landley.net>
Cc: qemu-devel@nongnu.org, "Edgar E. Iglesias" <edgar.iglesias@axis.com>

On Thu, Mar 06, 2008 at 12:47:12AM -0600, Rob Landley wrote:
> 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 

Yes, -L tries do map all paths. It's behavior depends on wether the file exists on the target dir or not. If the file does not exist on the target dir, I beleive it maps to the host fs. Also, it doesn't do anything with relative paths.

> 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...


Hmm, our (axis) version of busybox uses relative paths for all symbolic links. It might be patched though, I haven't dug very deep. But otherwise yes, absolute symbolic links need to be considered with the sysroot approach.

Best regards
-- 
Edgar E. Iglesias
Axis Communications AB