+++ 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?