Description of problem: If selinux is disabled on the RHEV-M host engine-setup does fail due to a failing selinux post scriplet in ovirt-vmconsole-proxy Version-Release number of selected component (if applicable): ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch How reproducible: always Steps to Reproduce: 1. Disable selinux completely (SELINUX=disabled) 2. Update/install RHEV so that ovirt-vmconsole-proxy package gets installed during setup Actual results: Setup fails due to a post scriplet that fails in ovirt-vmconsole-proxy package Expected results: Setup should work Additional info: Logs from the installer: 2016-06-02 11:12:12 DEBUG otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:91 Yum Done: ovirt-vmconsole.noarch 0:1.0.2-2.el6ev - u 2016-06-02 11:12:12 ERROR otopi.plugins.otopi.packagers.yumpackager yumpackager.error:100 Yum Non-fatal POSTIN scriptlet failure in rpm package ovirt-vmconsole-1.0.2-2.el6ev.noarch 2016-06-02 11:12:12 DEBUG otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:91 Yum Done: ovirt-vmconsole-1.0.2-2.el6ev.noarch 2016-06-02 11:12:12 DEBUG otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:91 Yum Done: ovirt-vmconsole-1.0.2-2.el6ev.noarch 2016-06-02 11:12:12 INFO otopi.plugins.otopi.packagers.yumpackager yumpackager.info:95 Yum update: 8/32: ovirt-vmconsole-proxy-1.0.2-2.el6ev.noarch 2016-06-02 11:12:43 DEBUG otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:91 Yum Script sink: SELinux is disabled. SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.24, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.24, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. /usr/sbin/semanage: Could not commit semanage transaction Post Script: fixfiles -R ovirt-vmconsole-proxy restore semanage port -a -t ovirt_vmconsole_proxy_port_t -p tcp 2222 || : chkconfig --add ovirt-vmconsole-proxy-sshd preuninstall scriptlet (using /bin/sh): if [ $1 -eq 0 ]; then semanage port -d -p tcp 2222 || : fi if [ $1 -eq 0 ]; then service ovirt-vmconsole-proxy-sshd stop > /dev/null 2>&1 || : chkconfig --del ovirt-vmconsole-proxy-sshd fi So in case selinux is disabled the semanage commands do fail. So we should check if selinux is enabled in case we want to run these commands, or we should change our documentation, requesting selinux at least in permissive mode. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html-single/Installation_Guide/index.html#Red_Hat_Enterprise_Linux_Hosts : ~~~ By default, SELinux is in enforcing mode upon installation. To verify, run getenforce. While it is highly recommended to have SELinux in enforcing mode, it is not required for Red Hat Enterprise Virtualization to host virtual machines. Disabling SELinux eliminates a core security feature of Red Hat Enterprise Linux. Problems also occur when migrating virtual machines between hypervisors that have different SELinux modes. For more information, see Red Hat Enterprise Linux 7 Virtualization Security Guide. ~~~
While I of course acknowledge the misbehaviour with selinux disabled, I'd like to stress out that the ovirt-vmconsole package, and oVirt in general, depends on selinux. In the case of ovirt-vmconsole, it _needs_ to update the configuration of selinux, and we can't distinguish between the case of selinux temporarily disabled -for whatever reason- or selinux permanently disabled. In the first case, if we skip the update of the selinux policies, we will have subtle and silent breakages once selinux is re-enabled.
I think it's safe to assume that if selinux is disabled it's not a temporary thing. (In reply to Francesco Romani from comment #1) > In the first case, if we skip the update of the selinux policies, we will > have subtle and silent breakages once selinux is re-enabled. That's more worrying since we would be preventing customers currently running with selinux disabled from enabling it in the future.
(In reply to Julio Entrena Perez from comment #2) > I think it's safe to assume that if selinux is disabled it's not a temporary > thing. > > (In reply to Francesco Romani from comment #1) > > In the first case, if we skip the update of the selinux policies, we will > > have subtle and silent breakages once selinux is re-enabled. > > That's more worrying since we would be preventing customers currently > running with selinux disabled from enabling it in the future. Let me elaborate on this: it is "just" that the selinux updates are done in the package scriptlets. If those selinux updates can be done manually (could be unpratical) or the package could be reinstalled (perhaps not much more pratical) nothing will break. The breakages I mentioned should mostly be SELinux denials, which aren't really that silent on the hosts (just need to check the system logs), but they are not reported to Engine AFAIU, so each host has to be checked and fixed manually. TL;DR we just expect the SElinux to be enabled :\
Thanks Francesco. (In reply to Francesco Romani from comment #3) > TL;DR we just expect the SElinux to be enabled :\ We need to be consistent though: - if we need selinux to be enabled then we need to document this (and check of the implications of introducing such requirement on existing deployments). - if we don't require selinux to be enabled then it must be possible to install engine with selinux disabled.
(In reply to Francesco Romani from comment #3) > (In reply to Julio Entrena Perez from comment #2) > > I think it's safe to assume that if selinux is disabled it's not a temporary > > thing. > > > > (In reply to Francesco Romani from comment #1) > > > In the first case, if we skip the update of the selinux policies, we will > > > have subtle and silent breakages once selinux is re-enabled. > > > > That's more worrying since we would be preventing customers currently > > running with selinux disabled from enabling it in the future. > > Let me elaborate on this: > > it is "just" that the selinux updates are done in the package scriptlets. > If those selinux updates can be done manually (could be unpratical) or the > package could be reinstalled (perhaps not much more pratical) nothing will > break. Indeed. And I think having a KBase about this (I used RHEV with SELinux disabled. Now I enabled it and $Thing doesn't work), describing what needs to be done in this case, would probably also help. > > The breakages I mentioned should mostly be SELinux denials, which aren't > really that silent on the hosts (just need to check the system logs), but > they are not reported to Engine AFAIU, so each host has to be checked and > fixed manually. Indeed, but this does not affect the hypervisors, but the manager, so every RHEV-M needs to be fixed manually (or every ovirt-console-proxy, which typically is the RHEV-Manager). > > TL;DR we just expect the SElinux to be enabled :\ Like Julio already said: As we document that selinux is not required, we should have our installation working with selinux disabled. Otherwise we should fix the documentation and set selinux as a requirement. See C#0 at the bottom for the current wording in our documentation.
indeed we need to be consistent SElinux is assumed to be enabled, if it's missing in the docs it needs to be added indeed. This particular issue can be easily skipped to unblock that, but we really don't want to encourage this behavior to install with completely disabled selinux as we can't really make sure stuff works if you then enable it later (it won't, actually) Sicne this is really a BAD practice I'm all for requiring (and checking for) selinux. Installling in Permissive mode is fine, disabling completely is not.
(In reply to Michal Skrivanek from comment #6) > indeed we need to be consistent > SElinux is assumed to be enabled, if it's missing in the docs it needs to be > added indeed. > This particular issue can be easily skipped to unblock that, but we really > don't want to encourage this behavior to install with completely disabled > selinux as we can't really make sure stuff works if you then enable it later > (it won't, actually) > Sicne this is really a BAD practice I'm all for requiring (and checking for) > selinux. Installling in Permissive mode is fine, disabling completely is not. I don't disagree, but there are customers who disabled SELinux in the RHEL 4 days when it was introduced and never looked back. For new deployments we should push for SELinux to be enabled, but we must carefully consider the implications of requiring customers to switch SELinux on in existing deployments, see bug 1271573 for an example.
(In reply to Julio Entrena Perez from comment #7) > For new deployments we should push for SELinux to be enabled, but we must > carefully consider the implications of requiring customers to switch SELinux > on in existing deployments, see bug 1271573 for an example. agreed. So the best course of action would be to 1) fix the semanage error in ovirt-vmconsole 2) require selinux in Enforcing or Permissive for new installation (new bug) however the fix is not trivial, it's in the preuninstall phase of 3.6 package so the fix needs to go there. The only workaround might be to temporarily enable selinux or to force remove rpm manually. Would that be ok?
I overlooked the fact it's in the post install only, so a 4.0 fix would suffice
Hi Michal, (In reply to Michal Skrivanek from comment #9) > I overlooked the fact it's in the post install only, so a 4.0 fix would > suffice I disagree here, as it currently prevents my customer from updating from 3.5 to 3.6 with engine-setup. As such I think a fix for RHEV 3.6 is also needed. So the easiest way from my PoV would be to check in the postinstall section for disabled selinux and in case it is disabled do not run the postinstall section. That said, fixing the selinux policy for ovirt-vmconsole in general would avoid the need for the postinstall section anyways. Thanks, Martin
Hi, a TAM customer of mine is experiencing the exact same issue. The reason why they have SELinux not enabled at all is that back in time there was no indication in the doc about the need of it, as there's no indication now. The perception and the confidence around SElinux has evolved during the years so this kind of situation is more common to happen to old 'loyal' customers. In general it would be great to offer to our older customer documentation and informations about the new pre-requisite of the product and how to evolve to comply with them. This bug is preventing my customer to upgrade his 5 RHEV environments from 3.5 to 3.6, so it's important here to have a fix for 3.6 as well. Thanks Andrea
(In reply to Andrea Perotti from comment #11) > and how to > evolve to comply with them. Currently it's not possible to transition to enabling SELinux due to bug 1271573 .
(In reply to Andrea Perotti from comment #11) > Hi, a TAM customer of mine is experiencing the exact same issue. > > The reason why they have SELinux not enabled at all is that back in time > there was no indication in the doc about the need of it, as there's no > indication now. > > The perception and the confidence around SElinux has evolved during the > years so this kind of situation is more common to happen to old 'loyal' > customers. > > In general it would be great to offer to our older customer documentation > and informations about the new pre-requisite of the product and how to > evolve to comply with them. > > This bug is preventing my customer to upgrade his 5 RHEV environments from > 3.5 to 3.6, so it's important here to have a fix for 3.6 as well. Ciao Andrea, this bug will be fixed by an updated ovirt-vmconsole package, which could be instalallable also on 3.6 environments. You can track this patch: https://gerrit.ovirt.org/#/c/59111/ I'll keep this a reminder to make it available on the proper channels.
(In reply to Francesco Romani from comment #13) > this bug will be fixed by an updated ovirt-vmconsole package, which could be > instalallable also on 3.6 environments. > You can track this patch: https://gerrit.ovirt.org/#/c/59111/ > I'll keep this a reminder to make it available on the proper channels. Ciao Francesco, I've reviewed the patch, thanks for the changes and the reply.
(In reply to Julio Entrena Perez from comment #12) > Currently it's not possible to transition to enabling SELinux due to bug > 1271573 . Yeah, that CU has been bitten by that situation too - and is solving it by turning the VMs off and on, on new SELinux enabled hypersors - but my question was limited in scope only to the manager, but that is matter for another topic, or another bugzilla. For the moment CU has solved installing that rpm in advance, to avoid the errors triggered by rpm while rhev is upgrading. Andrea
patch merged -> MODIFIED
*** Bug 1351355 has been marked as a duplicate of this bug. ***
worth fixing (just shipping) in 3.6 as it prevents upgrades
manually cloned to z-stream bug 1355686
ok, ovirt-vmconsole-1.0.4-1.el7ev.noarch tested with /usr/sbin/selinuxenabled' returning '0' and '1' ;) # rpm -qR ovirt-vmconsole-1.0.4-1.el7ev.noarch | egrep "selinux|policycoreutils" | sort | uniq libselinux-utils policycoreutils policycoreutils-python # rpm -q --scripts ovirt-vmconsole-1.0.4-1.el7ev.noarch | sed -n '/postinstall/,$p' postinstall scriptlet (using /bin/sh): if /usr/sbin/selinuxenabled ; then semodule -i "/usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp" fixfiles -R ovirt-vmconsole restore fi preuninstall scriptlet (using /bin/sh): if [ $1 -eq 0 ]; then if /usr/sbin/selinuxenabled ; then semodule -r ovirt_vmconsole fixfiles -R ovirt-vmconsole restore fi fi postuninstall scriptlet (using /bin/sh): if [ "$1" -ge "1" ]; then if /usr/sbin/selinuxenabled ; then semodule -i "/usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp" fi fi
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, 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://rhn.redhat.com/errata/RHEA-2016-1690.html