[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH] Re: option to have qemu chroot() into the target fi
[Qemu-devel] [PATCH] Re: option to have qemu chroot() into the target filesystem
Fri, 24 Oct 2008 18:06:10 -0500
On Friday 24 October 2008 04:21:29 Bernhard Reutner-Fischer wrote:
> A patch was in this thread:
> Rob promised to respin it tomorrow and resend it in to the list.
The debian bug report in question is:
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:
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.
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.
Description: Text Data
- [Qemu-devel] [PATCH] Re: option to have qemu chroot() into the target filesystem,
Rob Landley <=