Summary SELinux is preventing /sbin/losetup (fsadm_t) "append" to /var/run/xen- hotplug/block (udev_var_run_t). Detailed Description SELinux denied access requested by /sbin/losetup. It is not expected that this access is required by /sbin/losetup and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/run/xen-hotplug/block, restorecon -v /var/run/xen-hotplug/block If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:fsadm_t:SystemLow-SystemHigh Target Context system_u:object_r:udev_var_run_t Target Objects /var/run/xen-hotplug/block [ file ] Affected RPM Packages util-linux-2.13-0.45.el5_1.1 [application] Policy RPM selinux-policy-2.4.6-106.el5_1.3 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name serval.rheles5.it Platform Linux serval.rheles5.it 2.6.18-53.1.14.el5xen #1 SMP Tue Feb 19 07:33:17 EST 2008 x86_64 x86_64 Alert Count 18 Line Numbers Raw Audit Messages avc: denied { append } for comm="losetup" dev=dm-0 egid=0 euid=0 exe="/sbin/losetup" exit=0 fsgid=0 fsuid=0 gid=0 items=0 path="/var/run/xen- hotplug/block" pid=9210 scontext=system_u:system_r:fsadm_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:fsadm_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:udev_var_run_t:s0 tty=(none) uid=0
Xen is redirecting the stdout of losetup to a udev file, which is causing the AVC. It can safely be ignored.
This also could be a leaked file descriptor to /var/run/xen-hotplug/block
xend should not be leaking this file descriptor.
fcntl(fd, FD_SETFD, F_CLOSEXEC)
This is harder to address than one might think. The root cause is the Xen hotplug scripts all need to be serialized. This is achieved by creating a lock file and then flock()'ing it. Since the hotplug scripts are in shell, we have to use the 'flock' helper program. lockfd={a free file descriptor between 200 and 300} eval "exec $_lockfd>>/var/run/xen-hotplug/block" flock -x $_lockfd So, we'll typically open FD 200 and flock it. This is held for the duration of the hotplug scripts before being released. Unfortunately I cannot find any way to make this file descriptor FD_CLOEXEC. The line: eval "exec $_lockfd>>/var/run/xen-hotplug/block" always creates a filedescriptor which is inherited by child processes
*** Bug 434819 has been marked as a duplicate of this bug. ***
I'm closing this bz as I'm not able to reproduce this issue. If you hit this problem feel free to re-open.