Description of problem:
When doing an "xm reboot" with the new RHEL 5.1 xen bits, it fails to restart
the guest (and actually put xend into a funky state, which is a whole other
issue). The problem is that "xm reboot" calls out to pygrub, which, in the
latest bits, needs access to /usr/lib/fs (or /usr/lib64/fs on x86_64). However,
SELinux is preventing xend (which is in context root:system_r:xend_t) from
accessing these files, causing the reboot to fail. In particular, pygrub is
attempting to pathconf("/usr/lib/fs"), and is getting -EPERM back.
Unfortunately I do not have AVC's from this; I think I screwed up the audit
daemon on this machine, so I'm not getting anything out anymore.
If you need access to a box to see this in action, please let me know; I have a
machine available here that shows the problem.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Since Keyword Regression exists, this is a blocker,
not an exception. Cleared exception flag.
Set blocker flag."
Ok this bug is useless to me, In current policy xm is allowed to read lib_t
which is what /usr/lib/fs should be labeled as. So I have no idea what the
Hm, OK. I assume I would have to collect AVC's for this to be useful? I'll try
re-installing a 5.1 system from scratch and see if I can get some information
out of audit; disabling SELinux did solve the problem for me initially, so I
figured it was somewhere in there. I'll get back to you when I have more info.
*** This bug has been marked as a duplicate of 249895 ***