Bug 1914602

For me there is
[root@keytest ~]# ls -laZ /var/lib/ovirt-engine/external_truststore
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 997 Jan  7 16:23 /var/lib/ovirt-engine/external_truststore
also on a recent oVirt-4.4 setup.
Michael, can you please check in your environments?

Also installing current master, the problem does not reproduce:
[root@permtest ~]# ls -laZ /var/lib/ovirt-engine/external_truststore
-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 1000 Jan 11 10:41 /var/lib/ovirt-engine/external_truststore
[root@permtest ~]# rpm -qa ovirt-engine
ovirt-engine-4.4.5-0.0.master.20210110135511.gitfc28888a0cf.el8.noarch

Hi Chetan,

Can you please confirm the severity of the bug and attach the KCS for it?

We are considering closing this bug, since we cannot reproduce, we are considering closing this bug, so KCS would be extremely helpful here. (unless you can provide additional details, but it seems like the issue was cause by something outside of RHV and one time)

Thank you!

FWIW, managed to reproduce this bug by:

# umask 0027
# engine-setup

This causes /var/lib/ovirt-engine/external_truststore to be created with 0640 (root:root), and engine.log has:

2021-01-12 12:36:58,126+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-49) [12c14d61] EVENT_ID: PROVIDER_SYNCHRONIZED_FAILED(216), Failed to synchronize networks of Provider ovirt-provider-ovn.

This happens because normally, this file does not exist in new setups. It is created by the first command which imports stuff into it, which is in the setup plugin ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py . Perhaps we should create it (empty?) beforehand somewhere with correct permissions.

Workaround: Use "standard" umask 0022 when running engine-setup.

(In reply to Marina Kalinin from comment #5)
> Hi Chetan,
> 
> Can you please confirm the severity of the bug and attach the KCS for it?
> 
> We are considering closing this bug, since we cannot reproduce, we are
> considering closing this bug, so KCS would be extremely helpful here.
> (unless you can provide additional details, but it seems like the issue was
> cause by something outside of RHV and one time)
> 
> Thank you!

Any progress with the KCS?

(In reply to Martin Perina from comment #7)
> 
> Any progress with the KCS?

Did you notice comment 6? I think 'umask 027' should be considered "legitimate". If not, we should document this. I think adding chmod, chown or chgrp should not be that hard.

Verified
========
rhvm-4.4.5.7-0.1.el8ev.noarch

Regarded file permissions are correct (-rw-r--r--. 1 root root unconfined_u:object_r:var_lib_t:s0 1123 Feb 17 13:27 /var/lib/ovirt-engine/external_truststore) after
====================================================================================================================================================================
* Fresh deployment
* engine-setup
* umask 0027
  engine-setup

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 (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), 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/RHSA-2021:1169