Description of problem: SELinux is preventing /usr/sbin/brctl from read, append access on the file /run/libvirt/network/nwfilter.leases. ***** Plugin leaks (86.2 confidence) suggests ***************************** If sie den read append Zugriff von brctl, auf nwfilter.leases file ignorieren möchten, weil Sie glauben, dass dieser Zugriff nicht benötigt wird. Then sie sollten dies als Fehler melden. Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen. Do # grep /usr/sbin/brctl /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (14.7 confidence) suggests ************************** If sie denken, dass es brctl standardmässig erlaubt sein sollte, read append Zugriff auf nwfilter.leases file zu erhalten. Then sie sollten dies als Fehler melden. Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen. Do zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen: # grep brctl /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:brctl_t:s0-s0:c0.c1023 Target Context system_u:object_r:dnsmasq_var_run_t:s0 Target Objects /run/libvirt/network/nwfilter.leases [ file ] Source brctl Source Path /usr/sbin/brctl Port <Unknown> Host (removed) Source RPM Packages bridge-utils-1.5-10.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-103.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64 x86_64 Alert Count 2 First Seen 2014-12-20 13:45:25 CET Last Seen 2014-12-20 13:55:49 CET Local ID 3cb75563-89d7-415f-a67d-9f02891e2297 Raw Audit Messages type=AVC msg=audit(1419080149.761:491): avc: denied { read append } for pid=3799 comm="brctl" path="/run/libvirt/network/nwfilter.leases" dev="tmpfs" ino=24833 scontext=system_u:system_r:brctl_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dnsmasq_var_run_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1419080149.761:491): arch=x86_64 syscall=execve success=yes exit=0 a0=1e1d730 a1=1df7810 a2=1e18d00 a3=58c items=0 ppid=3759 pid=3799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=brctl exe=/usr/sbin/brctl subj=system_u:system_r:brctl_t:s0-s0:c0.c1023 key=(null) Hash: brctl,brctl_t,dnsmasq_var_run_t,file,read,append Version-Release number of selected component: selinux-policy-3.13.1-103.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.7-300.fc21.x86_64 type: libreport
This looks like a leaked file descriptor.
*** Bug 1178565 has been marked as a duplicate of this bug. ***
/run/libvirt/network/nwfilter.leases
dnsmasq configuration used by libvirt does not specify the nwfilter.leases file. I don't know what it's for and who creates it, but from the configuration it does not seem to be dnsmasq.
Description of problem: I started sudo virt-manager and added a new Windows host on Xen, using virtual NAT for network Version-Release number of selected component: selinux-policy-3.13.1-99.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.4-301.fc21.x86_64 type: libreport
*** Bug 1264646 has been marked as a duplicate of this bug. ***
Description of problem: Start virtual machine on Fedora 22 with xen Version-Release number of selected component: selinux-policy-3.13.1-128.16.fc22.noarch Additional info: reporter: libreport-2.6.2 hashmarkername: setroubleshoot kernel: 4.2.3-200.fc22.x86_64 type: libreport
Description of problem: Start Fedora 22 with xen Version-Release number of selected component: selinux-policy-3.13.1-128.16.fc22.noarch Additional info: reporter: libreport-2.6.2 hashmarkername: setroubleshoot kernel: 4.2.3-200.fc22.x86_64 type: libreport
Since libvirt never directly execs brctl (it does everything it needs with bridges via netlink or ioctl) I'm going to take a wild guess that something about the handling of the "ifup" script in the libxl driver is exec'ing it, but failing to close all open fds beforehand. Note that if you are using a <filter> in your <interface>, and are using the nwfilter parameter CTRL_IP_LEARNING, libvirt's nwfilter module will open nwfilter.leases and keep it open (see https://libvirt.org/formatnwfilter.html#nwfelemsRulesAdvIPAddrDetection ). However, any exec of an external program from code that is a part of libvirt itself will close all open file descriptors that haven't been explicitly marked as "pass to child". Does your guest have a <filter> in its interface (or maybe another guest has <filter> in an interface)? I'm guessing this should go to xen, but won't reassign it just yet.
In fact sudikeru can you provide the entire VM xml? sudo virsh --connect xen:/// dumpxml $VM-NAME
Description of problem: Start Fedora 22 Version-Release number of selected component: selinux-policy-3.13.1-128.16.fc22.noarch Additional info: reporter: libreport-2.6.3 hashmarkername: setroubleshoot kernel: 4.2.3-200.fc22.x86_64 type: libreport
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
sudikeru: along with reporting a recurrence of this problem (as you did yesterday), can you provide the information requested in Comment 10? Since you are still experiencing the problem and are running F22, I'm changing the Version field accordingly so the bug won't be automatically closed, but without proper info we'll have to close it anyway...
Since no one is responding to needinfo requests, just closing. If anyone is still hitting this in the future, please reopen with the info requested on comment #10