+++ This bug was initially created as a clone of Bug #877715 +++
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 };
--- Additional comment from Federico Simoncelli on 2012-11-18 08:34:21 EST ---
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)
--- Additional comment from cristi falcas on 2012-11-18 09:53:40 EST ---
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
--- Additional comment from Federico Simoncelli on 2012-11-19 14:42:18 EST ---
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?
--- Additional comment from Daniel Walsh on 2012-11-19 16:52:48 EST ---
/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?
--- Additional comment from Federico Simoncelli on 2012-11-20 08:04:34 EST ---
(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).
--- Additional comment from Daniel Walsh on 2012-11-21 10:21:48 EST ---
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?
Comment 4Federico Simoncelli
2013-01-14 08:09:03 UTC