Hide Forgot
Created attachment 481235 [details] Full logs. Description of problem: When trying to create a domain using vdsm and SELinux is on Enforcing mode error occurs: libvirtError: internal error process exited while connecting to monitor: qemu: could not open disk image /rhev/data-center/cc174bff-13d3-4ff4-a5cb-8ce6d019629e/b9750b78-f531-4161-ac3e-fe1805297861/images/9e1be145-d45e-4675-ad0e-a4d00cc71268/38aed963-1d27-4dae-9caa-e0af617f3b6d: Permission denied -audit log: type=AVC msg=audit(1298806134.799:1874): avc: denied { read } for pid=22774 comm="qemu-kvm" name="b9750b78-f531-4161-ac3e-fe1805297861" dev=dm-0 ino=130574 scontext=system_u: system_r:svirt_t:s0:c516,c959 tcontext=system_u:object_r:file_t:s0 tclass=lnk_file Version-Release number of selected component (if applicable): -vdsm-4.9-51.el6.x86_64 -libvirt-0.8.7-8.el6.x86_64 additional info: [root@XX cc174bff-13d3-4ff4-a5cb-8ce6d019629e]# ls -Z lrwxrwxrwx. vdsm kvm system_u:object_r:file_t:s0 b9750b78-f531-4161-ac3e-fe1805297861 -> /rhev/data-center/mnt/blockSD/b9750b78-f531-4161-ac3e-fe1805297861 lrwxrwxrwx. vdsm kvm system_u:object_r:file_t:s0 mastersd -> b9750b78-f531-4161-ac3e-fe1805297861 ps -Z unconfined_u:system_r:initrc_t:s0 17171 ? 00:00:15 vdsm unconfined_u:system_r:initrc_t:s0 17208 ? 00:00:00 supervdsmServer unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 16354 ? 00:00:05 libvirtd *full logs attached (libvird.log, vdsm.log and audit.log)
libselinux-utils-2.0.94-3.el6.x86_64 libselinux-python-2.0.94-3.el6.x86_64 selinux-policy-3.7.19-70.el6.noarch selinux-policy-targeted-3.7.19-70.el6.noarch libselinux-2.0.94-3.el6.x86_64
As I understand it, the image file is on NFS. So I'm assuming that the sebool virt_use_nfs is on, and it goes without saying that dynamic_ownership=0 in /etc/libvirt/qemu.conf. If that's the case, then it sounds like virt_use_nfs doesn't allow access to files via a symbolic link. However, on my RHEL6.1 test system, starting an image from a root_squash NFS share with a symbolic link in the path is successful *unless I turn off virt_use_nfs*; when I do that, it fails in exactly the same way. Can you verify that "getsebool virt_use_nfs" shows that it is "on"?
this is an iscsi domain and virt_use_nfs is on.
Okay, the next idea I have is that possibly dynamic_ownership=0 is set in /etc/libvirt/qemu.conf, and that is maybe causing a problem. Can you try restarting libvirtd after changing dynamic_ownership to 1, and see if that changes the behavior. (I know that you might not want to use a different configuration for installations using iscsi and those using nfs, but doing this temporarily may narrow down what needs to be fixed.) I also added dwalsh to the cc list, in case he has a comment about selinux+qemu vs. symlinks, or the label set on this particular symlink. Maybe the solution is as simple as having "whoever creates that symlink" label it correctly. (I did try starting a domain with 1) an image path that has a symlink, and 2) dynamic_ownership=0, and it was successful, so it's something more involved than that).
How is labeled /rhev # ls -dZ /rhev Just try to execute # restorecon -R -v /rhev
after examining the scenario it seems like /rhev/data-center labelling issue. the issue reproduced only in case rhev storage hierarchy was created when selinux was in disabled status, then when changing selinux config to enforcing and rebooting the host, the permission error occurs because of wrong labelling to /rhev/data-center... the issue fixed when i deleted /rhev/data-center and restarted vdsmd - /rhev/data-center was recreated with correct labelling.
reopening the bug on: vdsm-4.9-51.el6.x86_64 libvirt-0.8.7-8.el6.x86_64 libselinux-python-2.0.94-3.el6.x86_64 libselinux-2.0.94-3.el6.x86_64 libselinux-utils-2.0.94-3.el6.x86_64 selinux-policy-targeted-3.7.19-70.el6.noarch qarsh-selinux-1.26-3.el6.x86_64 selinux-policy-3.7.19-70.el6.noarch Reassign bug to SELinux group due to .autorelable file wasn't fixing the issue and still start vm get permission denied.
Created attachment 482506 [details] audit log
Created attachment 482507 [details] libvirt log
Created attachment 482508 [details] vdsm log
Created attachment 482509 [details] messages log
my scenario was: I get "Permission denied" every time i try to start VM. scenario: 1. disable selinux, restart machine and check that selinux is disable with "getenforce" command. 2. Configure a full datacenter2.3 setup with host rhel6, storageDomain (iscsi), isoDomain (nfs) and create VM's. 3. turned back selinux and reboot the machine 4. try to start the VM - Permission denied try to add ./autorelable and reboot but with no success. BTW following comment 6 wasn't fixing the issue as well
[root@south-01 ~]# ls -dZ /rhev drwxr-xr-x. root root system_u:object_r:mnt_t:s0 /rhev [root@south-01 ~]# ls -dZ /rhev/data-center/c57f0ca5-beef-4aff-a39a-dcc56bf2b61f/2282d409-38db-41c0-89be-d2dd9413b8b3/images/d4767da6-65ce-4692-8a8c-116d13632387/ drwxr-xr-x. vdsm kvm system_u:object_r:file_t:s0 /rhev/data-center/c57f0ca5-beef-4aff-a39a-dcc56bf2b61f/2282d409-38db-41c0-89be-d2dd9413b8b3/images/d4767da6-65ce-4692-8a8c-116d13632387/
Well, I don't think this is a bug. First you should not turn off SELinux. If so, you need to run restorecon on /rhev which you already have [root@south-01 ~]# ls -dZ /rhev drwxr-xr-x. root root system_u:object_r:mnt_t:s0 /rhev and now you should again create /rhev/data-center (comment #7) and it will work or you can run chcon command. # chcon -R -t mnt_t /rhev/data-center SELinux policy tells /rhev is a mount point and subdirectories won't be relabelled since we don't want to change any removable media by default.
Sorry, why is this closed again as not a bug? If you allow a RHEV host to be installed in disabled status, and it doesn't work when putting the host into enforcing... then it's a bug. This is definitely the fix: # chcon -R -t mnt_t /rhev/data-center But restorecon doesn't work -- so I think the labels need to be updated so that /rhev/data-center gets properly relabeled automatically.
(In reply to Stephen Benjamin from comment #16) > Sorry, why is this closed again as not a bug? > > If you allow a RHEV host to be installed in disabled status, and it doesn't > work when putting the host into enforcing... then it's a bug. > > This is definitely the fix: > > # chcon -R -t mnt_t /rhev/data-center > > But restorecon doesn't work -- so I think the labels need to be updated so > that /rhev/data-center gets properly relabeled automatically. Well this is expected. If you switch to enabled SELinux either you need to run chcon command or re-mount it.
> Well this is expected. If you switch to enabled SELinux either you need to run chcon command or re-mount it. I don't think remounting would work, going from disabled to enforcing is after a reboot and after relabeling, but /rhev/data-center doesn't end up with the right context. I would expect that our products handle relabeling correctly such that they work when a user goes from disabled to enforcing. Or just don't let RHEV get installed on a system with selinux disabled to begin with.
The point is we have $ matchpathcon /rhev/ /rhev system_u:object_r:mnt_t:s0 $ matchpathcon /rhev/data-center /rhev/data-center system_u:object_r:mnt_t:s0 $ matchpathcon /rhev/data-center/XXX /rhev/data-center/XXX <<none>> This is a reason why files won't be relabeled in /rhev/data-center/XXX which is correct. And if you re-mount it with enabled SELinux then it will work.