This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 215343 - [XEN] Have to restart xend to boot VMX guest with SDL.
[XEN] Have to restart xend to boot VMX guest with SDL.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
:
Depends On: 207771
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-13 11:37 EST by Chris Lalancette
Modified: 2010-07-19 09:27 EDT (History)
5 users (show)

See Also:
Fixed In Version: 5.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-05 09:56:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Failing domain config file from intel (7.13 KB, text/plain)
2006-12-28 15:22 EST, Chris Lalancette
no flags Details
Xend log from Intel (169.21 KB, text/plain)
2006-12-28 15:24 EST, Chris Lalancette
no flags Details
xend-debug log from Intel (216 bytes, text/plain)
2006-12-28 15:25 EST, Chris Lalancette
no flags Details
Xend.log corresponding to comment #27 failure (278.70 KB, text/plain)
2007-03-06 17:18 EST, Chris Lalancette
no flags Details
Audit log when failing to start SDL domain (5.20 KB, text/plain)
2007-03-09 09:40 EST, Chris Lalancette
no flags Details

  None (edit)
Description Chris Lalancette 2006-11-13 11:37:01 EST
+++ This bug was initially created as a clone of Bug #207771 +++

Description of problem:


Version-Release number of selected component (if applicable):
On FC6 Test3 I have to execute "xend stop; xend start" before can create the 
VMX guest, otherwise the vmx guest will not be created.

How reproducible:
1. start vncserver in fc6 test3.
2. Connect to the vncserver with using a remote vncviewer 
3. Try to create a vmx guest on the vncviewer console

I have more information from the customer; specifically, trying to start up a
fully-virtualized domain on x86_64 fails, with the following message in
/var/log/xen/qemu-dm.log:

domid: 2
qemu: the number of cpus is 1
shared page at pfn:7fff, mfn: 40cf6
buffered io page at pfn:7ffd, mfn: 40cf8
xs_read(): vncpasswd get error. /vm/be39e056-a12a-053d-19ae-10b4ec04060c/vncpasswd.
Could not initialize SDL - exiting 

Restarting xend seems to clear up the problem.  I took a quick look at the
initialization code; the error message corresponds to "SDL_Init()" failing.
Comment 2 Jay Turner 2006-11-22 08:39:22 EST
QE ack for RHEL5.
Comment 3 Daniel Berrange 2006-11-22 09:03:49 EST
Its unclear why VNC is showing errors if your setup to use SDL, unless perhaps
you're using both. We need more info to debug this. Please create attachments
containing

 - The guest config file from /etc/xen
 - /var/log/xend.log
 - /var/log/xend-debug.log
 - The most recent of the 'qemu-dm-*.log' files from /var/log/xen
Comment 9 Jeremy Katz 2006-12-04 16:18:22 EST
SDL just worked fine for me without having to restart the guest -- please
provide the guest config as well as how you're logging in
Comment 15 Jeremy Katz 2006-12-19 11:40:08 EST
I'm completely unable to reproduce this here.  Please provide the logs from the
failure as well as the config as I originally asked for. 
Comment 17 Chris Lalancette 2006-12-28 15:22:53 EST
Created attachment 144486 [details]
Failing domain config file from intel
Comment 18 Chris Lalancette 2006-12-28 15:24:34 EST
Created attachment 144487 [details]
Xend log from Intel
Comment 19 Chris Lalancette 2006-12-28 15:25:35 EST
Created attachment 144488 [details]
xend-debug log from Intel
Comment 22 Jeremy Katz 2007-01-03 13:41:45 EST
Are you doing anything "strange" with xauthority?  Are there any SELinux avcs?
Comment 25 Jay Turner 2007-02-07 09:43:59 EST
Intel is still seeing the same problems with a fresh Snapshot 7 installation.
Comment 27 Chris Lalancette 2007-03-06 17:09:22 EST
OK.  I can finally reproduce this, although I get a slightly different error
message from what was in this ticket before.  Here's the setup I have:

1.  RHEL-5 i386 dom0, SELinux enabled, fresh reboot.
2.  Start X, and log into the console.  This is critical, I don't get the same
problem when doing this via ssh.
3.  Install RHEL-5 as a fully virt guest, using: virt-install -n rhel5fvtest -r
500 -f /var/lib/xen/images/rhel5fvtest.dsk -s 6 --nonsparse --vnc -v -c
/var/lib/xen/images/boot.iso (boot.iso copied over from a RC tree)
4.  Do the install, accepting all defaults
5.  After the install, reboot, and then shut down the guest
6.  Edit the config file, comment out "vnc=1" and "vncunused=1", and add "sdl=1".
7.  Try to start the guest

In my case, I get the following in my qemu-dm log:

Xlib: connection to "localhost:0.0" refused by server
Xlib: No protocol specified

Xlib: connection to "localhost:0.0" refused by server
Xlib: No protocol specified

Could not initialize SDL - exiting

I also did a wireshark capture, and what I see is a pretty standard X11 Initial
Connection Request, but then the Initial Connection Reply has success=0, with a
reason of "No protocol specified."

I seem to be able to use one of three ways to get out of this:
1.  Turn off SELinux (i.e. setenforce 0).  Doing this will allow the SDL domain
to start, but as soon as you turn SELinux back on the domain will start failing
again.
2.  Run "xhost +" for the X server.  This will also allow the SDL domain to
start, but doing "xhost -" again causes it to start failing.
3.  Restart xend "xend start ; xend stop", as mentioned earlier in this ticket.
 This will allow the SDL domain to start, and will continue to allow SDL domains
to start, up until you restart the machine.

If anyone needs additional information, or a box to reproduce, let me know since
I now know how to do it.

Chris Lalancette
Comment 28 Daniel Berrange 2007-03-06 17:13:53 EST
Can you attach your latest  xend.log file corresponding to comment #27 - i want
to see the config XenD is getting when you created it via the console.
Comment 29 Chris Lalancette 2007-03-06 17:18:06 EST
Created attachment 149394 [details]
Xend.log corresponding to comment #27 failure
Comment 30 Chris Lalancette 2007-03-06 17:30:23 EST
I also just noticed that I am getting this on the terminal I started X (startx)
from:

AUDIT: Tue Mar  6 17:38:07 2007: 3484 X: client 16 rejected from IP 127.0.0.1
AUDIT: Tue Mar  6 17:38:07 2007: 3484 X: client 16 rejected from IP 127.0.0.1

I get two of those every time I try, and fail, to start an SDL domain.

Chris Lalancette
Comment 31 Chris Lalancette 2007-03-06 20:32:07 EST
The more I think about this, the more it seems to me an SELinux problem with
xend reading /root/.Xauthority (although I don't get any audit messages in
/var/log/audit):

1.  In the case of "xhost +", .Xauthority is completely ignored; so while xend
might fail to read .Xauthority, it doesn't actually matter since no
authentication is being used.
2.  In the case of SELinux being disabled, it obviously allows /root/.Xauthority
to be read.
3.  In the case of xend stop; xend start, it actually gets the context of the
user who ran it.  So, for instance, after a fresh boot, "ps -efwZ | grep xend"
looks like:

[root@lore ~]# ps -efwZ | grep xend
system_u:system_r:xend_t        root      2877     1  0 17:37 ?        00:00:00
python /usr/sbin/xend start
system_u:system_r:xend_t        root      2882  2877  0 17:37 ?        00:00:00
python /usr/sbin/xend start
system_u:system_r:xend_t        root      2883     1  0 17:37 ?        00:00:00
blktapctrl
root:system_r:unconfined_t:SystemLow-SystemHigh root 5363 5208  0 20:36 pts/2
00:00:00 grep xend

But after a xend stop; xend start, the same command looks like:

[root@lore ~]# ps -efwZ | grep xend
system_u:system_r:xend_t        root      2883     1  0 17:37 ?        00:00:00
blktapctrl
root:system_r:unconfined_t:SystemLow-SystemHigh root 5378 1  0 20:36 ? 00:00:00
python /usr/sbin/xend start
root:system_r:unconfined_t:SystemLow-SystemHigh root 5379 5378  0 20:36 ?
00:00:00 python /usr/sbin/xend start
root:system_r:unconfined_t:SystemLow-SystemHigh root 5400 5208  0 20:36 pts/2
00:00:00 grep xend

So it looks like xend got restarted as "unconfined_t", which now allows it to
read /root/.Xauthority, and it happily will do so until the next reboot (or
possibly, service xend restart), when xend gets reverted to xend_t.

Chris Lalancette
Comment 32 Chris Lalancette 2007-03-07 10:53:27 EST
Eureka!  Changing the context of /root to system_u:object_r:xen_image_t (from
root:object_r:user_home_dir_t), and changing the context of /root/.Xauthority to
the same, allows an SDL guest to start properly.  I'm sure this is the wrong
solution, but I just wanted to prove that this would do it.

Chris Lalancette
Comment 33 Chris Lalancette 2007-03-07 10:58:57 EST
Dan,
     I'm adding you to the CC list since I think this is an SELinux context
problem, despite the lack of relevant AVC's in /var/log/audit/audit.log.  To
summarize the situation (more details are in previous comments):

1.  Starting a Xen guest, at an X console (not via ssh), using SDL fails to
start with "Could not initialize SDL".
2.  Restarting xend by hand (i.e. # xend stop; xend start) "fixes" the problem
by changing the context of the xend process to unconfined_t.  Also, changing the
context of /root and /root/.Xauthority to system_u:object_r:xen_image_t also
fixes the problem.

It feels like xend needs to be able to read /root/.Xauthority in order to
successfully start up the new X window, but it is being prevented from doing so
by SELinux.  Please take a look and let me know if you have recommendations.

Thanks,
Chris Lalancette
Comment 34 Daniel Berrange 2007-03-07 11:05:15 EST
XenD really has no business being given access to per-user home directory files
like Xauthority. Looking at the source it appears possible to give Xen the path
to an alternate Xauthority file with the 'xauthority' config parameter. This
would let you re-point it at a file under /etc/xen, or /var/lib/xen where the
SELinux policy already allows writes.

IMHO, this is just another example illustrating the fundemental brokenness of
the whole SDL display idea though. You have to set Xauthority / display info at
guest startup, but you can't ever change it after that. A guest will likely
outlive the lifetime of your X session. In addition killing the X session will
kill the entire guest VM's device model. Add on top the SELinux security issues
in this ticket, and SDL becomes totally unsupportable.
Comment 35 Chris Lalancette 2007-03-07 16:16:47 EST
Dan,
     I don't necessarily disagree with your points.  However, I have been told
the policy is generally "if we ship it, we support it".  I'd like to see if the
SELinux people have any comment, or some tricky way out of this.  If not, we can
just release note it for now.

Chris Lalancette
Comment 36 Daniel Walsh 2007-03-09 08:45:16 EST
You can generate policy to allow the xend process to read the /root directory
with grep xen /var/log/audit/audit.log | audit2allow -M myxend  

Then load the generated pp file. 

We could add a boolean to selinux policy to allow xen to read /root directories,
but I agree with Daniel that this seems a little broken.
Comment 37 Chris Lalancette 2007-03-09 09:38:36 EST
Dan,
     Two things:

1.  There don't seem to be any relevant AVC's in /var/log/audit/audit.log; I'll
upload audit.log, if you'd like to look at them yourself.

2.  I still agree that letting xend tromp willy-nilly through the filesystem
seems bad, and is not something the policy should generally allow.  It's just
that this is shipped broken; it would be much better for customers, and for
support, if this actually worked.  Is it possible to set the default policy so
that xend could read only /root/.Xauthority, and nothing else?  I don't think
that would open up much of a security hole, and would be much better for
customers (and support) if this worked out-of-the-box, so to speak.

Chris Lalancette
Comment 38 Chris Lalancette 2007-03-09 09:40:47 EST
Created attachment 149687 [details]
Audit log when failing to start SDL domain

This is a fresh audit log from a failing SDL domain.  I did the equivalent of
the following:

rm -f /var/log/audit/audit.log ; reboot ; startx ; xm create rhel5fvtest

And then uploaded that resulting audit.log here.
Comment 40 Chris Lalancette 2007-10-05 09:56:50 EDT
The reporter of the initial bug said that he couldn't reproduce on 5.1.  I don't
think we did anything in particular to fix it, though.  Closing out as
CURRENTRELEASE.

Chris Lalancette
Comment 41 Chris Lalancette 2010-07-19 09:27:58 EDT
Clearing out old flags for reporting purposes.

Chris Lalancette

Note You need to log in before you can comment on or make changes to this bug.