Created attachment 695570 [details] Output of libvguestfs-test-tool (default attach to libvirt) Description of problem: Version-Release number of selected component (if applicable): libguestfs-1.20.1-3.fc18.x86_64 How reproducible: always Steps to Reproduce: Reconfigure libvirt to support non-root users to manage VMs $ sudo vi /etc/libvirt/libvirtd.conf unix_sock_group = "libvirt" unix_sock_rw_perms = "0770" unix_sock_dir = "/var/run/libvirt" auth_unix_ro = "none" auth_unix_rw = "none" Restart libvirtd, and add non-root user to group libvirt & qemu $ sudo systemctl restart libvirtd.service ; sudo usermod -aG jdoe libvirt; sudo usermod -aG jdoe qemu Set system-wide defaults on how to talk to libvirt: $ vi /etc/environment LIBVIRT_DEFAULT_URI=qemu:///system LIBGUESTFS_PATH=/var/lib/libguestfs/appliance LIBGUESTFS_ATTACH_METHOD=libvirt Prepare cached libguestfs appliance directory $ mkdir /var/lib/libguestfs $ chgrp libvirt /var/lib/libguestfs $ chmod 775 /var/lib/libguestfs $ pushd /var/lib/libguestfs $ wget http://libguestfs.org/download/binaries/appliance/appliance-1.20.0.tar.xz $ tar -xf appliance-1.20.0.tar.xz $ chown root:libvirt appliance -Rf $ find appliance -type f -exec chmod a+r {} + $ find appliance -type d -exec chmod a+rx {} + $ popd Run libguestfs-test-tool Actual results: libguestfs: [00848ms] launch libvirt guest libguestfs: error: could not create appliance through libvirt: internal error process exited while connecting to monitor: connect(unix:/tmp/libguestfsrXYwg2/console.sock): Permission denied chardev: opening backend "socket" failed [code=1 domain=10] Expected results: Additional info:
This happens even if you install Fedora 18 from scratch, install libguestfs and run libguestfs-test-tool. Here are the versions of things that I'm using: libvirt-daemon-qemu-0.10.2.3-1.fc18.x86_64 libguestfs-1.20.1-3.fc18.x86_64 kernel-3.6.10-4.fc18.x86_64 selinux-policy-3.11.1-66.fc18.noarch SELinux: Enforcing To reproduce it: (1) Install fresh Fedora 18 in a VM. (2) yum install libguestfs-tools (3) Run: libguestfs-test-tool My strong suspicion is the tmp-on-tmpfs misfeature (I always turn this crap off, so this is the first time I've tried to use it)
Nope, not tmp-on-tmpfs. An SELinux policy regression is my next suspicion. That seems to be confirmed because it works with SELinux set to Permissive. The AVCs are: ---- time->Tue Feb 12 08:51:46 2013 type=SYSCALL msg=audit(1360659106.570:463): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff38f4c720 a2=6e a3=22 items=0 ppid=1 pid=19417 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:svirt_tcg_t:s0:c566,c961 key=(null) type=AVC msg=audit(1360659106.570:463): avc: denied { connectto } for pid=19417 comm="qemu-system-x86" path="/tmp/libguestfsvxzNsI/console.sock" scontext=unconfined_u:system_r:svirt_tcg_t:s0:c566,c961 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket ---- time->Tue Feb 12 08:53:35 2013 type=SYSCALL msg=audit(1360659215.027:470): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff7d1c9a20 a2=6e a3=22 items=0 ppid=1 pid=19497 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:svirt_tcg_t:s0:c197,c461 key=(null) type=AVC msg=audit(1360659215.027:470): avc: denied { connectto } for pid=19497 comm="qemu-system-x86" path="/tmp/libguestfscYm9YD/console.sock" scontext=unconfined_u:system_r:svirt_tcg_t:s0:c197,c461 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket ---- time->Tue Feb 12 08:54:04 2013 type=SYSCALL msg=audit(1360659244.378:477): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff5f7edf30 a2=6e a3=22 items=0 ppid=1 pid=19575 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:svirt_tcg_t:s0:c173,c466 key=(null) type=AVC msg=audit(1360659244.378:477): avc: denied { connectto } for pid=19575 comm="qemu-system-x86" path="/tmp/libguestfsrh6cv2/console.sock" scontext=unconfined_u:system_r:svirt_tcg_t:s0:c173,c466 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket ---- time->Tue Feb 12 08:58:01 2013 type=SYSCALL msg=audit(1360659481.157:339): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff67a35bf0 a2=6e a3=22 items=0 ppid=1 pid=1953 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=3 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:svirt_tcg_t:s0:c413,c889 key=(null) type=AVC msg=audit(1360659481.157:339): avc: denied { connectto } for pid=1953 comm="qemu-system-x86" path="/tmp/libguestfsoFVWzi/console.sock" scontext=unconfined_u:system_r:svirt_tcg_t:s0:c413,c889 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket ---- time->Tue Feb 12 08:58:55 2013 type=SYSCALL msg=audit(1360659535.098:346): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff4407c0f0 a2=6e a3=22 items=0 ppid=1 pid=2032 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=3 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:svirt_tcg_t:s0:c295,c545 key=(null) type=AVC msg=audit(1360659535.098:346): avc: denied { connectto } for pid=2032 comm="qemu-system-x86" path="/tmp/libguestfsG4kOXh/console.sock" scontext=unconfined_u:system_r:svirt_tcg_t:s0:c295,c545 tcontext=unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023 tclass=unix_stream_socket
audit2allow suggests: #============= svirt_tcg_t ============== allow svirt_tcg_t svirt_socket_t:unix_stream_socket connectto;
Well not really a regression we had only added: \ allow svirt_t svirt_socket_t:unix_stream_socket connectto; e368e89e2f34694e966d02e7700dce8f11b399d5 fixes this in git.
Backported. commit 7f48d1d198809feb817246056b0695bea08ebbda Author: Dan Walsh <dwalsh> Date: Tue Feb 12 13:08:02 2013 -0500 Allow all svirt domains to connect to svirt_socket_t
selinux-policy-3.11.1-78.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-78.fc18
Package selinux-policy-3.11.1-78.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-78.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2588/selinux-policy-3.11.1-78.fc18 then log in and leave karma (feedback).
selinux-policy-3.11.1-78.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.