Hi, Description of problem: After upgrading my ovirt-engine to 4.4.2, I can no longer upgrade a host, or have it checked for updates. The culprit seems to be a wrong label and/or selinux policy change for /var/log/ovirt-engine/ansible-runner-service.log. The default label for this file is var_log_t. When this label is applied to the file, checking for updates/upgrading a host fails. When the label is changed to httpd_log_t, it works again. So either the log file should have an updated selinux label in the policy, or the selinux policy should be updated to allow httpd_t to open the var_log_t file. Regards, Rik Version-Release number of selected component (if applicable): ovirt-engine-tools-4.4.2.6-1.el8.noarch How reproducible: Steps to Reproduce: 1. Upgrade engine to 4.4.2 2. Try to check for updates on a host 3. Actual results: Fails and the following selinux AVC is logged: type=AVC msg=audit(1600372500.464:14501): avc: denied { open } for pid=3713150 comm="httpd" path="/var/log/ovirt-engine/ansible-runner-service.log" dev="dm-0" ino=917760 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1 Expected results: Check for updates (or upgrading a host) works Additional info:
Are you sure that you have finished upgrading oVirt 4.4.2 properly according to upgrade guide? https://www.ovirt.org/documentation/upgrade_guide/#Updating_the_Red_Hat_Virtualization_Manager_minor_updates Have you executed 'yum update' after engine-setup to finish upgrading non oVirt packages? In this particular case could you please check that you are using ansible-runner-service-1.0.5?
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
(In reply to Martin Perina from comment #1) > Are you sure that you have finished upgrading oVirt 4.4.2 properly according > to upgrade guide? > > https://www.ovirt.org/documentation/upgrade_guide/ > #Updating_the_Red_Hat_Virtualization_Manager_minor_updates > > Have you executed 'yum update' after engine-setup to finish upgrading non > oVirt packages? > In this particular case could you please check that you are using > ansible-runner-service-1.0.5? Yes, I'm running ansible-runner-service-1.0.5 This update was installed on 2020-07-29 already, where I upgraded the engine to 4.4.2 yesterday I see that the chcon is run from the postinst of that package. It does however not seem to add it as an exception to the policy, so any restorecon runs will override the change again. It's not listed in the 'semanage fcontext --list -C' output. That output does include some other exceptions however. Regards, Rik
I'm able to reproduce this. I think this is a very critical issue, because it is not possible to add new hosts to a 4.4.2 cluster with selinux enabled. type=AVC msg=audit(1600526662.121:136): avc: denied { open } for pid=1548 comm="httpd" path="/var/log/ovirt-engine/ansible-runner-service.log" dev="dm-0" ino=36140918 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0 Workaround: 1) Turn selinux off: setenforce 0 2) Add new hosts to the engine / check for updates 3) Turn selinux on: setenforce 1
Hi Morton, (In reply to Morten Stevens from comment #4) > I'm able to reproduce this. I think this is a very critical issue, because > it is not possible to add new hosts to a 4.4.2 cluster with selinux enabled. > > type=AVC msg=audit(1600526662.121:136): avc: denied { open } for pid=1548 > comm="httpd" path="/var/log/ovirt-engine/ansible-runner-service.log" > dev="dm-0" ino=36140918 scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0 > > Workaround: > > 1) Turn selinux off: setenforce 0 > 2) Add new hosts to the engine / check for updates > 3) Turn selinux on: setenforce 1 A better workaround is to manually relabel the file (as the postinst of ansible-runner-service does): chcon -t httpd_log_t /var/log/ovirt-engine/ansible-runner-service.log Regards, Rik
Verified with ansible-runner-service-1.0.6-2.el8ev.noarch
Since the error message in 4.4.2 refers to the file that cannot be written to, a different error message should be returned to the user in case ansible cannot launch?
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.