Description of problem: Storage can't be activated Version-Release number of selected component (if applicable): using nightly builds How reproducible: always Steps to Reproduce: 1. run allinone engine-setup 2. 3. Actual results: engine-setup can't add storage Expected results: setup is finishing successfully Additional info: Errors from logs: Nov 18 00:09:00 localhost setroubleshoot: SELinux is preventing /usr/sbin/sanlock from search access on the directory 7274c859-af87-4b43-8e2a-575bf12ca395. For complete SELinux messages. run sealert -l 01cc54bc-514a-4027-b401-1912f8b1bd87 Nov 18 00:09:00 localhost setroubleshoot: SELinux is preventing /usr/sbin/sanlock from search access on the directory 7274c859-af87-4b43-8e2a-575bf12ca395. For complete SELinux messages. run sealert -l 01cc54bc-514a-4027-b401-1912f8b1bd87 Nov 18 00:09:00 localhost setroubleshoot: SELinux is preventing /usr/sbin/sanlock from search access on the directory 7274c859-af87-4b43-8e2a-575bf12ca395. For complete SELinux messages. run sealert -l 01cc54bc-514a-4027-b401-1912f8b1bd87 Nov 18 00:09:00 localhost setroubleshoot: SELinux is preventing /usr/sbin/sanlock from getattr access on the file /media/ceva2/Ovirt/Storage/7274c859-af87-4b43-8e2a-575bf12ca395/dom_md/leases. For complete SELinux messages. run sealert -l 9cb938a3-6271-486a-9b1e-695fc46670e5 Nov 18 00:09:01 localhost vdsm Storage.LVM WARNING lvm vgs failed: 5 [] [' Volume group "7274c859-af87-4b43-8e2a-575bf12ca395" not found'] sealert command: [root@localhost Ovirt]# sealert -l 01cc54bc-514a-4027-b401-1912f8b1bd87 SELinux is preventing /usr/sbin/sanlock from search access on the directory 7274c859-af87-4b43-8e2a-575bf12ca395. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that sanlock should be allowed search access on the 7274c859-af87-4b43-8e2a-575bf12ca395 directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sanlock /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:sanlock_t:s0-s0:c0.c1023 Target Context system_u:object_r:public_content_rw_t:s0 Target Objects 7274c859-af87-4b43-8e2a-575bf12ca395 [ dir ] Source sanlock Source Path /usr/sbin/sanlock Port <Unknown> Host localhost.localdomain Source RPM Packages sanlock-2.4-2.fc17.x86_64 Target RPM Packages Policy RPM selinux-policy-3.10.0-159.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 3.6.6-1.fc17.x86_64 #1 SMP Mon Nov 5 21:59:35 UTC 2012 x86_64 x86_64 Alert Count 3 First Seen 2012-11-16 11:14:43 EET Last Seen 2012-11-18 00:09:00 EET Local ID 01cc54bc-514a-4027-b401-1912f8b1bd87 Raw Audit Messages type=AVC msg=audit(1353190140.472:11106): avc: denied { search } for pid=11908 comm="sanlock" name="7274c859-af87-4b43-8e2a-575bf12ca395" dev="dm-12" ino=4464651 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir type=AVC msg=audit(1353190140.472:11106): avc: denied { read write } for pid=11908 comm="sanlock" name="leases" dev="dm-12" ino=4456463 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=file type=AVC msg=audit(1353190140.472:11106): avc: denied { open } for pid=11908 comm="sanlock" path="/media/ceva2/Ovirt/Storage/7274c859-af87-4b43-8e2a-575bf12ca395/dom_md/leases" dev="dm-12" ino=4456463 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=file type=SYSCALL msg=audit(1353190140.472:11106): arch=x86_64 syscall=open success=yes exit=ENOMEM a0=7f50b8000b48 a1=105002 a2=0 a3=0 items=0 ppid=1 pid=11908 auid=4294967295 uid=179 gid=179 euid=179 suid=179 fsuid=179 egid=179 sgid=179 fsgid=179 tty=(none) ses=4294967295 comm=sanlock exe=/usr/sbin/sanlock subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null) Hash: sanlock,sanlock_t,public_content_rw_t,dir,search audit2allow #============= sanlock_t ============== allow sanlock_t public_content_rw_t:dir search; #!!!! The source type 'sanlock_t' can write to a 'file' of the following types: # sanlock_var_run_t, virt_var_lib_t, sanlock_log_t, nfs_t, root_t allow sanlock_t public_content_rw_t:file { read write open }; audit2allow -R #============= sanlock_t ============== allow sanlock_t public_content_rw_t:dir search; #!!!! The source type 'sanlock_t' can write to a 'file' of the following types: # sanlock_var_run_t, virt_var_lib_t, sanlock_log_t, nfs_t, root_t allow sanlock_t public_content_rw_t:file { read write open };
Can you report the components version: fedora release (fc17/18), selinux-policy version. What's the sebool status? # getsebool -a | egrep "(sanlock_use|virt_use_sanlock)" On fedora 18 this is not specific to sanlock, for what I see the method we currently use to set the sebool options is broken, in fact also other booleans are not set: virt_use_nfs --> off virt_use_sanlock --> off sanlock_use_nfs --> off The issue I'm hitting is: # semanage boolean -l | grep virt_use_nfs Traceback (most recent call last): File "/usr/sbin/semanage", line 25, in <module> import seobject File "/usr/lib64/python2.7/site-packages/seobject.py", line 30, in <module> import sepolgen.module as module ImportError: No module named sepolgen.module (Failure within the pre scriptlet in the spec file)
This is on fedora 17 Packages versions: rpm -qa | grep selinux libselinux-2.1.10-3.fc17.i686 libselinux-python-2.1.10-3.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 libselinux-utils-2.1.10-3.fc17.x86_64 selinux-policy-targeted-3.10.0-159.fc17.noarch selinux-policy-devel-3.10.0-159.fc17.noarch selinux-policy-3.10.0-159.fc17.noarch sebool: getsebool -a | egrep "(sanlock_use|virt_use_sanlock)" sanlock_use_fusefs --> off sanlock_use_nfs --> on sanlock_use_samba --> off virt_use_sanlock --> on
Daniel do you think it would be possible to grant open, read and write permissions to sanlock for public_content_rw_t? Will you add a new boolean for that?
/media/ceva2/Ovirt/Storage/7274c859-af87-4b43-8e2a-575bf12ca395/dom_md/leases is labeled public_content_rw_t? Why is that? What content is in these directories? I see this content with no labels on it?
(In reply to comment #4) > /media/ceva2/Ovirt/Storage/7274c859-af87-4b43-8e2a-575bf12ca395/dom_md/leases > is labeled public_content_rw_t? > > Why is that? What content is in these directories? > > I see this content with no labels on it? /media/ceva2/Ovirt/Storage/7274c859-af87-4b43-8e2a-575bf12ca395 contains a set of files (and directories) that should be accessed by vdsm (eg: metadata), qemu (eg: vm images) and sanlock (eg: leases).
None of those require public_content, This is used for apache/ftp files not images. IMages should be labeled virt_image_t. leases should probably be labeled sanlock_var_run_t. Not sure what label vdsm runs with virtd_t?
Created attachment 661550 [details] 0001-Add-proper-label-for-sanlock-leases.patch (In reply to comment #6) > None of those require public_content, This is used for apache/ftp files not > images. > > IMages should be labeled virt_image_t. leases should probably be labeled > sanlock_var_run_t. Not sure what label vdsm runs with virtd_t? I don't think leases should be labeled as sanlock_var_run_t but they should their own specific type: sanlock_lease_t. I attached a patch for the selinux refpolicy. That said, on the VDSM side we have two options, either we start labeling files in the storage domains (where possible) or we don't use sanlock on local storage domains.
Is there a security difference? Ie should we allow/prevent domains from reading sanlock_var_run_t differently then sanlock_lease_t? Do you have file context for sanlock_lease_t?
(In reply to comment #8) > Is there a security difference? Ie should we allow/prevent domains from > reading sanlock_var_run_t differently then sanlock_lease_t? Technically at the moment there's not much difference (but for example sanlock_lease_t has nothing to do with files_pid_filetrans). The lases are first-class citizens in sanlock and they deserve their own type. I'm working on restricting the access a little bit more (we can probably grant only read/write on sanlock_lease_t to sanlock_t). > Do you have file context for sanlock_lease_t? No, not yet, sanlock doesn't impose where the leases are created by the applications (which are also responsible to correctly set the context at the moment).
I74070ebb: misc: rename safelease to clusterlock [1] I78072254: domain: select the cluster lock using makeClusterLock [2] I106618a9: clusterlock: add the local locking implementation [3] [1] http://gerrit.ovirt.org/#/c/10067/ [2] http://gerrit.ovirt.org/#/c/10281/ [3] http://gerrit.ovirt.org/#/c/10282/
vdsm-4.10.3-6.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-1775/vdsm-4.10.3-6.fc18
vdsm-4.10.3-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/vdsm-4.10.3-7.fc18
Package vdsm-4.10.3-7.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 vdsm-4.10.3-7.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2581/vdsm-4.10.3-7.fc18 then log in and leave karma (feedback).
vdsm-4.10.3-7.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.