Bug 1146886
Summary: | [DAC] permission denied with auto generated channel socket path when set user as root in qemu.conf | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Wayne Sun <gsun> |
Component: | libvirt | Assignee: | Martin Kletzander <mkletzan> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.1 | CC: | dyuan, gsun, lmiksik, mkletzan, mzhan, rbalakri, tlavigne, zhwang |
Target Milestone: | rc | Keywords: | Upstream |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.2.17-10.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-19 05:53:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Wayne Sun
2014-09-26 10:02:55 UTC
I can produce this bug on build with another way libvirt-1.2.8-16.el7.x86_64 1. make sure user and group with default in qemu.conf user = "qemu" group = "qemu" 2. prepare a guest, configure qemu-guest agent and the per-image dac differently with security_driver # virsh edit rl ... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rhel7_l.img'/> <seclabel model='dac' relabel='yes'> <label>test1:test1</label> </seclabel> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> ... <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/rl.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> ... <seclabel type='static' model='dac' relabel='yes'> <label>test1:test1</label> </seclabel> 3. change the owner/group of /var/lib/libvirt/qemu directory #chown test1:test1 /var/lib/libvirt/qemu 4. start guest failed # virsh start rl error: Failed to start domain rl error: internal error: process exited while connecting to monitor: 2015-02-25T03:07:29.682009Z qemu-kvm: -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channel/target/rl.org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied 2015-02-25T03:07:29.682168Z qemu-kvm: -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channel/target/rl.org.qemu.guest_agent.0,server,nowait: chardev: opening backend "socket" failed 5. if delete qemu-guest agent in guest xml, guest could be start success It should be the same root cause with this bug, so add comment (In reply to vivian zhang from comment #2) This does not make any sense, what would you like this to do? You are starting a domain as qemu:qemu and setting the socket to test1:test1. (In reply to Martin Kletzander from comment #3) > (In reply to vivian zhang from comment #2) > This does not make any sense, what would you like this to do? You are > starting a domain as qemu:qemu and setting the socket to test1:test1. hi, Martin thanks for your reminder Yes, you are right. I should keep the permission of start domain and the socket setting the same, guest start could success. when configure guest xml with <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/rl.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> 1. qemu.conf -> user=qemu group=qemu # ll -Z /var/lib/libvirt/qemu/ srwxr-x---. qemu qemu system_u:object_r:qemu_var_run_t:s0 capabilities.monitor.sock drwxr-x---. qemu qemu system_u:object_r:qemu_var_run_t:s0 channel drwxr-xr-x. root root system_u:object_r:qemu_var_run_t:s0 dump drwx--x--x. qemu qemu system_u:object_r:qemu_var_run_t:s0 nvram srwxr-xr-x. qemu qemu system_u:object_r:qemu_var_run_t:s0 rl.monitor srwxr-xr-x. qemu qemu system_u:object_r:qemu_var_run_t:s0 rl.org.qemu.guest_agent.0 drwxr-xr-x. qemu qemu system_u:object_r:qemu_var_run_t:s0 save drwxr-xr-x. qemu qemu system_u:object_r:qemu_var_run_t:s0 snapshot 2. qemu.conf -> user=test1 group=test1 # ll -Z /var/lib/libvirt/qemu/ srwxr-x---. qemu qemu system_u:object_r:qemu_var_run_t:s0 capabilities.monitor.sock drwxr-x---. qemu qemu system_u:object_r:qemu_var_run_t:s0 channel drwxr-xr-x. root root system_u:object_r:qemu_var_run_t:s0 dump drwx--x--x. qemu qemu system_u:object_r:qemu_var_run_t:s0 nvram srwxr-xr-x. test1 test1 system_u:object_r:qemu_var_run_t:s0 rl.monitor srwxr-xr-x. test1 test1 system_u:object_r:qemu_var_run_t:s0 rl.org.qemu.guest_agent.0 drwxr-xr-x. test1 test1 system_u:object_r:qemu_var_run_t:s0 save drwxr-xr-x. test1 test1 system_u:object_r:qemu_var_run_t:s0 snapshot Looks like we'll need a new directory for each guest since each guest can run uder different users. Could you also share the permissions for the /var/lib/libvirt/qemu/ directory itself? Does it also fail without that channel? Adding multiple needinfos, anyone feel free to reply and clear both, thanks. For comment 7's needinfo The permissions of the /var/lib/libvirt/qemu directory will change to root:root automatically while we Initializa libvirtd service after set user/group to root:root in qemu.conf, and the guest could start successfully if we remove the channel # ll /var/lib/libvirt/qemu/ -d drwxr-x---. 7 root root 4096 Aug 5 17:28 /var/lib/libvirt/qemu/ # ll /var/lib/libvirt/qemu/ total 20 srwxr-x---. 1 qemu qemu 0 Aug 5 17:27 capabilities.monitor.sock drwxr-x---. 3 qemu qemu 4096 Jan 28 2015 channel drwxr-xr-x. 2 qemu qemu 4096 Aug 4 11:00 dump drwx--x--x. 2 qemu qemu 4096 Jan 28 2015 nvram drwxr-xr-x. 2 root root 4096 Jul 27 16:19 save drwxr-xr-x. 4 root root 4096 Aug 4 21:12 snapshot BTW, couldn't reproduce the comment0's issue after libvirt-1.2.15-1.el7.x86_64 For the comment8's needinfo I have a doubt that will you create new directorys for each guest in this bz, so that each guest could run under different users. On the other hand if we implement this function, the following issue will be solved [Description] The guest will run under qemu user by default according to the qemu.conf , if we want to run guest with other users with per-vm dac, the guest will fail to start since permission deny [steps] 1.keep default configure for user/group in qemu.conf user=qemu group=qemu 2.Check the qemu directory permissions # ll /var/lib/libvirt/qemu/ -d drwxr-x---. 7 qemu qemu 4096 Aug 5 18:01 /var/lib/libvirt/qemu/ 3.Create a user useradd test1 4.Prepare a guests run under test1 #virsh dumpxml test1 -- <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/tmp/virt-test-smoke-16/shared/data/images/jeos-19-64.qcow2'> <seclabel model='dac' relabel='yes'> <label>test1:test1</label> </seclabel> </source> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> -- <seclabel type='static' model='dac' relabel='yes'> <label>test1:test1</label> </seclabel> 5.start the guest, the guest will fail to start since its didn't have permission access /var/lib/libvirt/qemu directory # virsh start virt-tests-vm1 error: Failed to start domain virt-tests-vm1 error: internal error: process exited while connecting to monitor: 2015-08-05T10:04:51.700297Z qemu-kvm: -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/virt-tests-vm1.monitor,server,nowait: Failed to bind socket to /var/lib/libvirt/qemu/virt-tests-vm1.monitor: Permission denied 6.change the /var/lib/libvirt/qemu directory's permission to test1, then re-start guest, guest could start successfully # chown test1:test1 qemu # ll /var/lib/libvirt/qemu/ -d drwxr-x---. 7 test1 test1 4096 Aug 5 18:04 /var/lib/libvirt/qemu/ # virsh start virt-tests-vm1 Domain virt-tests-vm1 started Upstream patch proposed: https://www.redhat.com/archives/libvir-list/2015-August/msg00589.html Fixed upstream by v1.2.18-168-gf1f68ca33433: commit f1f68ca33433825ce0deed2d96f1990200bc6618 Author: Martin Kletzander <mkletzan> Date: Fri Aug 7 14:42:31 2015 +0200 qemu: Fix access to auto-generated socket paths The following were my current verification steps and the basic functions of the patch works well currently Prepare test env 1.Create a user test1 and prepare 2 vms with guest agent configured #useradd test1 # virsh list --all Id Name State ---------------------------------------------------- - vm1 shut off - vm2 shut off # ll /var/lib/libvirt/qemu/ -d drwxr-x---. 7 qemu qemu 4096 Sep 8 11:16 /var/lib/libvirt/qemu/ Test scenarios scenario 1 1.Keep default configuration in qemu.conf 2.let vm1 running under qemu 3.configure per-vm dac for vm2 and let vm2 run under test1 #virsh dumpxml vm2 -- </devices> <seclabel type='static' model='dac' relabel='yes'> <label>test1:test1</label> </seclabel> </domain> 4.Start vm1 and vm2, vm1 could start successfully, however vm2 will fail to start since test1 didn't have access to open the /var/lib/libvirt/qemu directory, we can make it works by add "x" permission to /var/lib/libvirt/qemu directory #virsh start vm1 # virsh start vm1 Domain vm1 started # ps -efZ|grep vm1 system_u:system_r:svirt_t:s0:c938,c991 qemu 16713 1 46 11:19 ? 00:00:16 /usr/libexec/qemu-kvm -name vm1 # virsh start vm2 error: Failed to start domain vm2 error: internal error: process exited while connecting to monitor: 2015-09-08T03:21:45.143066Z qemu-kvm: -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-vm2/monitor.sock,server,nowait: Failed to bind socket to /var/lib/libvirt/qemu/domain-vm2/monitor.sock: Permission denied #chmod +x /var/lib/libvirt/qemu # ll /var/lib/libvirt/qemu/ -d drwxr-x--x. 7 qemu qemu 4096 Sep 8 16:14 /var/lib/libvirt/qemu/ # virsh start vm2 Domain vm2 started # ps aux|grep vm2 test1 4790 110 5.0 1524668 409588 ? Sl 16:36 0:11 /usr/libexec/qemu-kvm -name vm2 5.Check /var/lib/libvirt/qemu directory, we could find 2 new directory created basingthe guest name and the guest's monitor locate under this directory; check /var/lib/libvirt/qemu/channal/tartget directory we could also find 2 new directory created basing the guest name and guest agent socket located under the channel directory. BTW, all this directroy and socket files were labeled with selinux and dac correctly # ll /var/lib/libvirt/qemu/ -Z drwxr-xr-x. qemu qemu system_u:object_r:svirt_image_t:s0:c265,c563 domain-vm1 drwxr-xr-x. test1 test1 system_u:object_r:svirt_image_t:s0:c445,c789 domain-vm2 # ll /var/lib/libvirt/qemu/domain-vm1/ -Z srwxrwxr-x. qemu qemu system_u:object_r:svirt_image_t:s0:c265,c563 monitor.sock [root@server ~]# ll /var/lib/libvirt/qemu/domain-vm2/ -Z srwxrwxr-x. test1 test1 system_u:object_r:svirt_image_t:s0:c445,c789 monitor.sock # ll /var/lib/libvirt/qemu/channel/target/ -Z drwxr-xr-x. qemu qemu system_u:object_r:svirt_image_t:s0:c265,c563 domain-vm1 drwxr-xr-x. test1 test1 system_u:object_r:svirt_image_t:s0:c445,c789 domain-vm2 # ll /var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0 -Z srwxrwxr-x. qemu qemu system_u:object_r:svirt_image_t:s0:c265,c563 /var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0 [root@server ~]# ll /var/lib/libvirt/qemu/channel/target/domain-vm2/org.qemu.guest_agent.0 -Z srwxrwxr-x. test1 test1 system_u:object_r:svirt_image_t:s0:c445,c789 /var/lib/libvirt/qemu/channel/target/domain-vm2/org.qemu.guest_agent.0 6.Destroy the guest, all these new created directory and socket files will be removed scenario 2 1.excute step 1~3 in sceanaro 1 2.Restore /var/lib/libvirt/qemu directory to default permissions and Add test1 to qemu group #chmod 750 /var/lib/libvirt/qemu #useradd -a -G qemu test1 # id test1 uid=1000(test1) gid=1000(test1) groups=1000(test1),107(qemu) 3.Start the 2 guests, both of the 2 guests could start successfully # virsh start vm1 vDomain vm1 started # virsh start vm2 Domain vm2 started # ps aux|grep vm1 qemu 6161 25.5 10.2 1646532 823384 ? Sl 16:52 0:23 /usr/libexec/qemu-kvm -name vm1 # ps aux|grep vm2 test1 6221 18.6 9.3 1527744 749564 ? Sl 16:52 0:17 /usr/libexec/qemu-kvm -name vm2 4.excute step 5~6 in sceanrio 1, could get the same result with sceanrio 1 scenario 3 1.Set user=root group=root in qemu.conf, then re-test scenario 1 and scenario2 all steps could get the expect result scenario 4 some Negative test scenarios 1.configure an unexsiting user in vm2, start guest, could get the expect error # id test20 id: test20: no such user #virsh dumpxml vm2 -- </devices> <seclabel type='static' model='dac' relabel='yes'> <label>test20:test20</label> </seclabel> </domain> # virsh start vm2 error: Failed to start domain vm2 error: invalid argument: Failed to parse user 'test20' 2.create the 2 directorys which named domain-vm1 domain-vm2 under /var/lib/libvirt/qemu/ directory, then start the guest, the guest could start successfully and directorys and socket files were labeled by selinux and dac correctly 3.Set dac seclabel=none in guest's xml, start guest will get the expect error #virsh dumpxml vm2 -- </devices> <seclabel type='none' model='dac'/> </domain> # virsh start vm2 error: Failed to start domain vm2 error: internal error: process exited while connecting to monitor: 2015-09-08T09:57:04.584142Z qemu-kvm: -drive file=/tmp/virt-test-smoke-46/shared/data/images/jeos-19-64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2: Could not open '/tmp/virt-test-smoke-46/shared/data/images/jeos-19-64.qcow2': Permission denied Hi Martin Find following 2 issues during verify this bug with negative testing, please help check whether they deserve fixed in this bug or we file new bugs to track them, thanks pkginfo libvirt-1.2.17-8.el7.x86_64 qemu-kvm-rhev-2.3.0-22.el7.x86_64 Issue 1 will get unclear error while pre-create a file which have same name with the guest before we start it steps 1.Prepare a guest # virsh list --all Id Name State ---------------------------------------------------- - vm1 shut off 2.Pre-create a file which have same name with the guest before we start it #touch /var/lib/libvirt/qemu/domain-vm1 # ll /var/lib/libvirt/qemu/domain-vm1 -rw-r--r--. 1 root root 0 Sep 8 19:03 /var/lib/libvirt/qemu/domain-vm1 3.Start the guest, will get an unclear error # virsh start vm1 error: Failed to start domain vm1 error: An error occurred, but the cause is unknown Issue 2 guest will crash while start guest with invalid vnc socket path steps 1.Prepare a guest # virsh list --all Id Name State ---------------------------------------------------- - vm1 shut off 2.enable vnc_auto_unix_socket in qemu.conf #cat /etc/libvirt/qemu.conf vnc_auto_unix_socket = 1 #service libvirtd restart 3.Configure an invalid vnc socket path in guest's xml #virsh dumpxml vm1 -- <graphics type='vnc' socket='/var/lib/libvirt/qemu/domain-vm111/a.vnc'/> 4.Start guest, guest will crash # virsh start vm2 error: Failed to start domain vm2 error: internal error: early end of file from monitor: possible problem: qemu-kvm: iohandler.c:60: qemu_set_fd_handler2: Assertion `fd >= 0' failed. Regarding permissions for /var/lib/libvirt/qemu/, those should be 0751 as you mentioned and I will post a fix for that, thanks for finding that out, my permissions when testing were different there. Regarding the "issue is unknown" error, that should be fixed, but the fix is simple, I'll post a patch for that as well. Regarding the invalid path, well, that is expected since you supplied the path yourself, hence libvirt will not automatically generate that one and depends on you to create it. If the path is supplied, then for libvirt it doesn't matter whether it starts with /var/lib/libvirt or anything else. Once it's supplied, it is your responsibility to make sure the path is accessible. That was the case before as well and the main reason for that is that then you could create the path starting anywhere (e.g. /etc/shadow) and we should definitely not touch that. (In reply to zhenfeng wang from comment #16) One more thing to note here, about the invalid path. The error in comment #16 is a bit weird and BZ should be created for that as what I get is _expected_ error that makes sense when reproducing that with random machine: error: internal error: process exited while connecting to monitor: 2015-09-08T13:14:33.882947Z qemu-system-arm: -vnc unix:/var/lib/libvirt/qemu/domain-vm111/a.vnc: Failed to start VNC server: Failed to bind socket to /var/lib/libvirt/qemu/domain-vm111/a.vnc: No such file or directory Patches proposed upstream: https://www.redhat.com/archives/libvir-list/2015-September/msg00295.html https://www.redhat.com/archives/libvir-list/2015-September/msg00296.html Additional details fixed with following upstream commits: commit 8370023730220fcf48f9b1fa0914b60c66452569 Author: Martin Kletzander <mkletzan> Date: Tue Sep 8 19:12:58 2015 +0200 qemu: Report error if per-VM directory cannot be created commit 192a13948905668955ff39e32d4622f8511fadf0 Author: Martin Kletzander <mkletzan> Date: Sat Sep 12 15:00:58 2015 +0200 qemu: Do not allow others into per-VM subdirectories commit f05f005c8b0ec8a53bb7fd6da65f4ac08afac858 Author: Martin Kletzander <mkletzan> Date: Tue Sep 8 18:34:36 2015 +0200 qemu: Allow others to browse /var/lib/libvirt/qemu One more patch is missing in order not to pollute logs with false positive errors, mainly after upgrading the daemon with running VM: https://www.redhat.com/archives/libvir-list/2015-September/msg00506.html I'll move it back to POST when back-ported. Probably tomorrow. Hopefully last fix upstream: commit b421a70811b15a2d1853ee7e47069fdef83f7f22 Author: John Ferlan <jferlan> Date: Tue Sep 15 16:33:36 2015 -0400 virfile: Check for existence of dir in virFileDeleteTree 1.Retest comment15 with libvirt-1.2.17-11.el7.x86_64, all steps could get the expect result 2.Could found the x permission added by default for the /var/lib/libvirt/qemu directory and other users didn't have permission into per-VM subdirectories anymore # ll /var/lib/libvirt/qemu/ -d drwxr-x--x. 7 qemu qemu 4096 Sep 30 13:43 /var/lib/libvirt/qemu/ # ll /var/lib/libvirt/qemu/domain-vm1/ -dZ drwxr-x---. qemu qemu system_u:object_r:svirt_image_t:s0:c659,c1003 /var/lib/libvirt/qemu/domain-vm1/ # ll -Z /var/lib/libvirt/qemu/channel/target/domain-vm1/ -d drwxr-x---. qemu qemu system_u:object_r:svirt_image_t:s0:c659,c1003 /var/lib/libvirt/qemu/channel/target/domain-vm1/ 3.Do some free testing for these 2 guests <1.enable panic in the guest's xml, and configure on_crash event "coredump-restart" "coredump-destroy" for the guests, the guest could generate the dump file correctly, also dump file could analysed successfully <2.Do managedsave/start for the guests, both of the 2 guest's could generated save file under /var/lib/libvirt/qemu/save and could restore correctly 4.Pre-create a file which have same name with the guest before we start it, guest will fail to start and get the following error #touch /var/lib/libvirt/qemu/domain-vm1 #touch /var/lib/libvirt/qemu/domain-vm2 # virsh start vm1 error: Failed to start domain vm1 error: Cannot create directory '/var/lib/libvirt/qemu/domain-vm1': Not a directory # virsh start vm2 error: Failed to start domain vm2 error: Cannot create directory '/var/lib/libvirt/qemu/domain-vm2': Not a directory 5.Pre-create directory and file for guest agent, guest could start successfully and guest agent works well #mkdir /var/lib/libvirt/qemu/channel/target/domain-vm1/ #touch /var/lib/libvirt/qemu/channel/target/domain-vm/org.qemu.guest_agent.0 # ll /var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0 -Z -rw-r--r--. root root unconfined_u:object_r:qemu_var_run_t:s0 /var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0 # virsh start vm1 Domain vm1 started # ll /var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0 -Z srwxrwxr-x. qemu qemu system_u:object_r:svirt_image_t:s0:c99,c812 /var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0 # virsh domtime vm1 --pretty Time: 2015-09-30 09:18:12 6.Destroy the guest, the direcotry and file will be deleted automatically # virsh destroy vm1 Domain vm1 destroyed # ll /var/lib/libvirt/qemu/channel/target/domain-vm1/-d ls: cannot access /var/lib/libvirt/qemu/channel/target/domain-vm1/-d: No such file or directory According to upper steps, mark this bug verifed Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2202.html |