From: Rob Landley <rob@landley.net>
To: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Cc: qemu-devel@nongnu.org, 415996@bugs.debian.org
Subject: [Qemu-devel] [PATCH] Re: option to have qemu chroot() into the target filesystem
Date: Fri, 24 Oct 2008 18:06:10 -0500 [thread overview]
Message-ID: <200810241806.10698.rob@landley.net> (raw)
In-Reply-To: <20081024092129.GA5952@mx.loc>
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
On Friday 24 October 2008 04:21:29 Bernhard Reutner-Fischer wrote:
> A patch was in this thread:
> http://www.mail-archive.com/qemu-devel@nongnu.org/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.
[-- Attachment #2: chroot2.patch --]
[-- Type: text/x-diff, Size: 1696 bytes --]
Index: linux-user/main.c
===================================================================
--- linux-user/main.c (revision 5527)
+++ linux-user/main.c (working copy)
@@ -2186,6 +2186,10 @@
"-cpu model select CPU (-cpu ? for list)\n"
"-drop-ld-preload drop LD_PRELOAD for target process\n"
"\n"
+ "Root options:\n"
+ "-chroot dir chroot to dir\n"
+ "-su uid:gid set numeric user and group IDs\n"
+ "\n"
"Debug options:\n"
"-d options activate log (logfile=%s)\n"
"-p pagesize set the host page size to 'pagesize'\n"
@@ -2301,6 +2305,28 @@
drop_ld_preload = 1;
} else if (!strcmp(r, "strace")) {
do_strace = 1;
+ } else if (!strcmp(r, "chroot")) {
+ if (chdir(argv[optind++]) || chroot(".")) {
+ fprintf(stderr, "Can't chroot to '%s' (are you root?)\n",
+ argv[--optind]);
+ _exit(1);
+ }
+ } else if (!strcmp(r, "su")) {
+ int temp;
+ char *gid = strchr(argv[optind], ':');
+ if (gid) {
+ temp = atoi(++gid);
+ if (setresgid(temp, temp, temp)) {
+ fprintf(stderr, "Can't set gid to %d (are you root?)\n",
+ temp);
+ _exit(1);
+ }
+ }
+ temp = atoi(argv[optind++]);
+ if (setresuid(temp, temp, temp)) {
+ fprintf(stderr, "Can't set uid to %d (are you root?)\n", temp);
+ _exit(1);
+ }
} else
{
usage();
next parent reply other threads:[~2008-10-24 23:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081024092129.GA5952@mx.loc>
2008-10-24 23:06 ` Rob Landley [this message]
2008-10-25 8:09 ` [Qemu-devel] [PATCH] Re: option to have qemu chroot() into the target filesystem Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810241806.10698.rob@landley.net \
--to=rob@landley.net \
--cc=415996@bugs.debian.org \
--cc=qemu-devel@nongnu.org \
--cc=rep.dot.nop@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.