All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xensource.com>
Subject: Re: PATCH: Set close-on-exec flag for QEMU disks
Date: Tue, 6 Mar 2007 16:34:15 +0000	[thread overview]
Message-ID: <20070306163415.GH29872@redhat.com> (raw)
In-Reply-To: <45EC8A5F.3020308@us.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On Mon, Mar 05, 2007 at 03:23:43PM -0600, Anthony Liguori wrote:
> Keir Fraser wrote:
> >On 2/3/07 21:40, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> >
> >  
> >>QEMU does not currently set the close-on-exec flag after opening its 
> >>virtual
> >>disk images. This causes problems when it later runs the 
> >>/etc/xen/qemu-ifup
> >>script because the file descriptors get propagated to networking commands
> >>like brctl / ifconfig. The SELinux policy quite rightly does not allow the
> >>networking scripts to access the virtual disk images, so these inherited
> >>file descriptors for AVC denials to be logged.
> >>
> >>The attached patch modifies all the QEMU disk driver backends to make sure
> >>the close-on-exec flag is turned on
> >>    
> >
> >It would be nicer to implement an open_cloexec() function in e.g., vl.c to
> >do the open() and fcntl() in one go and in one place.
> >  
> 
> There are few areas where scripts are executed.  Why not just introduce 
> an exec() wrapper that closes file descriptors appropriately.

Looking at the QEMU code in Xen there are only two places where exec is
used, and one of those is for the vncviewer spawning which isn't upstream.
One of them uses execlp() while the other uses execv(). So rather than 
doing a refactoring of code which will lead to even more divergance with
upstream, the attached patch just fixes up those 2 locations to close all
file handles upto sysconf(_SC_OPEN_MAX), with exception of STDIN/OUT/ERR
and the TAP deevice handle.

   Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

I've tested against Xen 3.0.4 in Fedora to validate neither the qemu-ifup
or vncviewer processes receive any extraneous file handles. The attached
patch applies cleanly to xen-unstable.hg too

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

[-- Attachment #2: xen-qemu-close-fds-2.patch --]
[-- Type: text/plain, Size: 1416 bytes --]

diff -r 3ac19fda0bc2 tools/ioemu/vl.c
--- a/tools/ioemu/vl.c	Fri Mar 02 12:11:52 2007 +0000
+++ b/tools/ioemu/vl.c	Tue Mar 06 11:21:52 2007 -0500
@@ -3250,6 +3250,14 @@ static int net_tap_init(VLANState *vlan,
         pid = fork();
         if (pid >= 0) {
             if (pid == 0) {
+                int open_max = sysconf (_SC_OPEN_MAX), i;
+                for (i = 0; i < open_max; i++)
+                    if (i != STDIN_FILENO &&
+                        i != STDOUT_FILENO &&
+                        i != STDERR_FILENO &&
+                        i != fd)
+                        close(i);
+
                 parg = args;
                 *parg++ = (char *)setup_script;
                 *parg++ = ifname;
diff -r 3ac19fda0bc2 tools/ioemu/vnc.c
--- a/tools/ioemu/vnc.c	Fri Mar 02 12:11:52 2007 +0000
+++ b/tools/ioemu/vnc.c	Tue Mar 06 11:21:52 2007 -0500
@@ -1445,7 +1445,7 @@ int vnc_display_init(DisplayState *ds, i
 
 int vnc_start_viewer(int port)
 {
-    int pid;
+    int pid, i, open_max;
     char s[16];
 
     sprintf(s, ":%d", port);
@@ -1456,6 +1456,12 @@ int vnc_start_viewer(int port)
 	exit(1);
 
     case 0:	/* child */
+	open_max = sysconf (_SC_OPEN_MAX);
+	for (i = 0; i < open_max; i++)
+	    if (i != STDIN_FILENO &&
+		i != STDOUT_FILENO &&
+		i != STDERR_FILENO)
+		close(i);
 	execlp("vncviewer", "vncviewer", s, NULL);
 	fprintf(stderr, "vncviewer execlp failed\n");
 	exit(1);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

      reply	other threads:[~2007-03-06 16:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-02 21:40 PATCH: Set close-on-exec flag for QEMU disks Daniel P. Berrange
2007-03-05 13:25 ` Keir Fraser
2007-03-05 21:23   ` Anthony Liguori
2007-03-06 16:34     ` Daniel P. Berrange [this message]

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=20070306163415.GH29872@redhat.com \
    --to=berrange@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=keir@xensource.com \
    --cc=xen-devel@lists.xensource.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.