Bug 857556 - selinux rules don't survive after rebooting the host
selinux rules don't survive after rebooting the host
Status: CLOSED UPSTREAM
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
3.1 GA
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Douglas Schilling Landgraf
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-14 15:59 EDT by exploit
Modified: 2012-10-25 11:30 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-25 11:30:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description exploit 2012-09-14 15:59:12 EDT
Description of problem:
vms don't start anymore after rebooting the host. the output error is "VM testVm is down. Exit message: internal error Failed to open socket to sanlock daemon: permission denied" 
I supposed it could be a selinux issue and getsebool -a | grep virt gives :
virt_use_nfs --> off
virt_use_sanlock --> off
when doing 
setsebool virt_use_sanlock=on
setsebool virt_use_nfs=on

now vms can start

but after rebooting selinux rules disppear and vms can't start anymore

Version-Release number of selected component (if applicable):

vdsm 4.10.0.6
How reproducible:

installing engine and vdsm and starting vms, even after rebooting
Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
after adding the persistent flag -F, rules survive after rebooting.
setsebool -F virt_use_sanlock=on
something must lack into the vdsm spec
Comment 1 Ayal Baron 2012-09-15 16:12:33 EDT
What platform are you running on? versions?
selinux version?
Comment 2 Douglas Schilling Landgraf 2012-09-15 22:42:02 EDT
Hi,

As Ayal shared, can you please share platform (Fedora? Centos?, etc) and versions?

Digging the case, here some notes:

We had a recently change that moved the selinux from vdsm init script to vdsm spec file [1], basically it's to improve the time for vdsm start.

Here the current code from spec file:

virtNFS=$(/usr/sbin/semanage boolean -l | /bin/grep virt_use_nfs | cut -d ',' -f 2)
virtSANLOCK=$(/usr/sbin/semanage boolean -l | /bin/grep virt_use_sanlock | cut -d ',' -f 2)

The above lines will share the status of virt_use_sanlock and virt_use_nfs  booleans, 'on' or 'off'

Example in Fedora 17:

off:
=====
/usr/sbin/semanage boolean -l | /bin/grep virt_use_nfs | cut -d ',' -f 2
  off)  virt_use_nfs

on:
=====
/usr/sbin/semanage boolean -l | /bin/grep virt_use_nfs | cut -d ',' -f 2
   on)  virt_use_nfs

Now, we are going to check if the return of command contain "off" and if yes, we will change it *and* __persist__ across reboots:

if [[ "${virtNFS}" == *off* || "${virtSANLOCK}" == *off* ]]; then
    /usr/sbin/semanage boolean -m -S targeted -F /dev/stdin  << _EOF
virt_use_nfs=1
virt_use_sanlock=1
_EOF
fi

here we are going to enable in the current memory:
if /usr/sbin/selinuxenabled; then
    /usr/sbin/setsebool virt_use_nfs on
    /usr/sbin/setsebool virt_use_sanlock on
fi

I have re-read the IRC logs and found this from the output of your semanage boolean -l | /bin/grep virt_use_nfs | cut -d ',' -f 2:

<glafouille> locked) virt_use_nf

No "on" or "off", looks like this is our problem, sharing more data from your system will help us to determine a possible solution.

Thanks for your report!

# rpm -qa | grep -i selinux
selinux-policy-devel-3.10.0-145.fc17.noarch
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-3.10.0-145.fc17.noarch
selinux-policy-targeted-3.10.0-145.fc17.noarch

# cat /etc/fedora-release 
Fedora release 17 (Beefy Miracle)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=832199
Comment 3 exploit 2012-09-16 17:54:49 EDT
hello guys, something new : 
before, in the aim to answer to Ayal, my version are the same as above (F17 and selinux 3.10) but I can reproduce the issue on centos with the dreyou repo so I think the bug doesn't come from any plateform or selinux version.
This is what I've discovered :
doing semanage boolean -l | /bin/grep virt_use_nfs | cut -d ',' -f 2
gives
ouvert)  virt_use_nfs
"ouvert" is the french word for "on" and before it was "fermé" (=off)
 my locale is :
[root@khamsin ~]# echo $LANG
fr_FR.UTF-8

so to my mind, it is not a real bug because I guess you write your script is in an English locale and the semanage command above waits for an English word "on" or "off". When the install script doesn't understand "fermé", it considers that it has nothing to do, and that's why virt_sanlock stays on "off" instead of "on".

An independant locale variable script could be the solution.
Comment 4 Douglas Schilling Landgraf 2012-09-19 13:49:51 EDT
Hi,

[1] Patch available upstream for review:
http://gerrit.ovirt.org/#/c/8068/

Test executed:
================
1) Setting a non English locale
# export LC_ALL=pt_BR (I am from Brazil =:P)

2) Disable virt_use_sanlock and virt_use_nfs booleans
#  /usr/sbin/semanage boolean -m -S targeted -F /dev/stdin  << _EOF
virt_use_nfs=0
virt_use_sanlock=0
_EOF

3) Check the status
# semanage boolean -l (returns 'desativado' (which means off) for virt_use_nfs and virt_use_sanlock)

4) Generate a vdsm package with the new patch [1] and install it

5) Now, check the current status of virt_use_sanlock and virt_use_nfs booleans, in portuguese it should be 'ativado' which means 'on' in English.
# semanage boolean -l

Thanks
Douglas

Note You need to log in before you can comment on or make changes to this bug.