[Qemu-devel] [PATCH] Re: option to have qemu chroot() into the target filesystem

[Rob Landley]

On Friday 24 October 2008 04:21:29 Bernhard Reutner-Fischer wrote:
> A patch was in this thread:
> http://www.mail-archive.com/address@hidden/msg16297.html
>
> Rob promised to respin it tomorrow and resend it in to the list.
> thanks

The debian bug report in question is:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415996

I checked and the old patch still applies cleanly (well, with an offset, but 
no fuzz).  I applied it and then did an svn diff, the result of which is 
attached.  (As with all svn diffs, it applies with "patch -p0 -i blah.patch")

It's actually a very simple patch, which does this:

A) Teach qemu-$TARGET to do a chdir() plus chroot() in response to a -chroot 
command line option.

B) Because A) requires root access, teach qemu-$TARGET to change uid and gid 
via a -su option (and set both the real and effective user IDs so it's 
actually dropping priviledges).

C) Add error handling if any of the above fails.  (I.E. I check the return 
code so that if you _don't _drop privs I'm not introducing a security hole.)

D) Add help text entries describing the new options.

The only objection to the original patch was that there's one case it doesn't 
cover; if the emulated process does an "exec" of another target binary, qemu 
doesn't handle that:
http://www.mail-archive.com/qemu-devel%40nongnu.org/msg16496.html

In my opinion this boils down to "qemu doesn't do something before this patch, 
and still doesn't do it afterwards either".  That's really a separate issue, 
which can be addressed later if necessary.

Rob

P.S.  I note that I did _not_ check to make sure that "qemu-arm -su" actually 
has an argument after it to avoid a segfault, but 
then "qemu-arm -cpu", "qemu-arm -s", "qemu-arm -g"  and so on all segfault in 
exactly the same way, so that's another separate issue if anybody cares.

chroot2.patch
Description: Text Data