Description of problem: If SELinux is disabled, then the directory "selinux" will not be available under sys filesystem. === ~]# getenforce Disabled ~]# ls /sys/fs/selinux ls: cannot access /sys/fs/selinux: No such file or directory === However, when imgbased tries to mount the selinuxfs, it will try to create the selinux directory under sys filesystem. As per the logic, the mount point will be created by the imgbased if the directory doesn't exist. === src/imgbased/plugins/osupdater.py 770 with utils.mounted("selinuxfs", 771 target=new_fs.target + 772 "/sys/fs/selinux", 773 fstype="selinuxfs"): src/imgbased/utils.py 227 if not os.path.exists(self.target): 228 self.run.call(["mkdir", "-p", self.target]) ==== Since sysfs is not writable filesystem, it will fail with error "Operation not permitted" when it tries to create directory "/sys/fs/selinux". ==== 2019-06-21 12:30:05,018 [DEBUG] (run_rpm_selinux_post) Calling: (['mount', u'/dev/rhvh_md2-rhvn1/rhvh-4.3.0.8-0.20190610.0+1', u'/tmp/mnt.47yq9'],) {'close_fds': True, 'stderr': -2} 2019-06-21 12:30:06,190 [DEBUG] (run_rpm_selinux_post) Calling: (['mount', '-tsysfs', 'sys', u'/tmp/mnt.47yq9/sys'],) {'close_fds': True, 'stderr': -2} 2019-06-21 12:30:06,196 [DEBUG] (run_rpm_selinux_post) Calling binary: (['mkdir', '-p', u'/tmp/mnt.47yq9/sys/fs/selinux'],) {} 2019-06-21 12:30:06,196 [DEBUG] (run_rpm_selinux_post) Calling: (['mkdir', '-p', u'/tmp/mnt.47yq9/sys/fs/selinux'],) {'close_fds': True, 'stderr': -2} 2019-06-21 12:30:06,201 [DEBUG] (run_rpm_selinux_post) Exception! mkdir: cannot create directory '/tmp/mnt.47yq9/sys/fs/selinux': Operation not permitted ==== Version-Release number of selected component (if applicable): imgbased-1.1.5-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Disable SELinux in RHV-H and ty to upgrade it. 2. 3. Actual results: Upgrading the RHV-H will fail if the SELinux is disabled in the server Expected results: Upgrade should work. Additional info:
Nijin, can you share the use case for having selinux disabled?
Asking because selinux should be enforcing there according to bug #1349241
Also, Nijin, is this a beta system? I see imgbased 1.1.5 but in RHV 4.3 GA we shipped 1.1.7 and upgrade from beta to GA is not supported. That said, upgrade with selinux disbaled should work since we fixed it in bug #1542833 so we need to reproduce on supported configuration.
(In reply to Sandro Bonazzola from comment #2) > Asking because selinux should be enforcing there according to bug #1349241 I already asked the customer but doesn't get a response. However, now we are trying to upgrade with SELinux enabled but getting some other errors which we are currently troubleshooting. (In reply to Sandro Bonazzola from comment #3) > Also, Nijin, is this a beta system? I see imgbased 1.1.5 but in RHV 4.3 GA > we shipped 1.1.7 and upgrade from beta to GA is not supported. > That said, upgrade with selinux disbaled should work since we fixed it in > bug #1542833 so we need to reproduce on supported configuration. Sorry about that. Looks like I reproduced in an old beta server. However, I just tried to upgrade from 4.2 to 4.3 and can clearly reproduce it with mentioned reproducer steps. It fails when it tries to create the directory "/tmp/mnt.WHo1r/sys/fs/selinux". Attaching the imgbased.log.
Honestly a RHV-H should always have selinux in enforcing. If a customer disables it, upgrade *should* fail from my pov, as it really weakens security. In addition there is no reason for disabling selinux. So in case we don't fail the upgrade, we should ensure that we enable selinux (enforcing) at the very minimum. Every boot of a RHV-H system should automatically check if selinux is in enforcing and put it in enforcing in case it is not. If customers want to run with less security they can still use a RHEL based installation. The RHV-H should not allow a setup with selinux disabled.
This is something the RHV Upgrade Helper (https://access.redhat.com/labs/rhvupgradehelper/) should call out SELinux status as a requirement. We cannot just fail an upgrade without giving customers the chance to remediate any issues.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (RHV Host (redhat-virtualization-host) 4.4), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:3316