Description of problem: As described in bug 1264701, when selinux is disabled, selinux.restorecon fails with ENODATA when restoring contents of a file created when selinux was disabled. VDSM works around this issue by using the following idiom: if selinux.is_selinux_enabled(): selinux.restorecon(path) As newer versions of libselinux handle this scenario internally, we can consume them and remove this workaround from VDSM's code. Requirements: Fedora: libselinux-2.4-4 (see https://bugzilla.redhat.com/show_bug.cgi?id=1264701#c8) RHEL: libselinux-2.5-2.el7 (see https://bugzilla.redhat.com/show_bug.cgi?id=1264701) Version-Release number of selected component (if applicable): 4.17.999
Verified with the following code: ------------------------------------- ovirt-engine-4.2.0-0.5.master.el7.noarch vdsm-4.20.8-53.gitc3edfc0.el7.centos.x86_64 Verified with the following scenario: ------------------------------------- Scenario 1: --------------- [root@green-vdsb ~]# touch /etc/multipath.conf.new [root@green-vdsb ~]# python Python 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import selinux >>> selinux.restorecon("/etc/multipath.conf.new") >>> Scenario 2: -------------- mount | grep selinux rm -f /etc/multipath.conf.new python Python 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import selinux >>> import os >>> os.system('ls -Z /etc/multipath.conf.new') ls: cannot access /etc/multipath.conf.new: No such file or directory 512 >>> os.system('touch /etc/multipath.conf.new') 0 >>> os.system('ls -Z /etc/multipath.conf.new') -rw-r--r-- root root ? /etc/multipath.conf.new 0 >>> selinux.restorecon('/etc/multipath.conf.new') >>> os.system('ls -Z /etc/multipath.conf.new') -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/multipath.conf.new 0 >>> Moving to VERIFIED
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.