Bug 1342270

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