Bug 1047392

Summary: dwh service fails to read Default.properties, 10-setup-database.conf is world-readable
Product: Red Hat Enterprise Virtualization Manager Reporter: Yedidyah Bar David <didi>
Component: ovirt-engine-dwhAssignee: Yedidyah Bar David <didi>
Status: CLOSED ERRATA QA Contact: Tareq Alayan <talayan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: acathrow, iheim, pstehlik, Rhev-m-bugs, scohen, talayan, yeylon, ylavi
Target Milestone: ---Keywords: Triaged
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: integration
Fixed In Version: IS30 - rhevm-dwh-3.3.0-27.el6ev.src.rpm Doc Type: Bug Fix
Doc Text:
rhevm-dwh used to run as root, but now it runs as ovirt. Condequently there are two different files with database access credentials. This update makes these files owned by root:ovirt and perms 0640, read-only for ovirt and unreadable for everyone else.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-21 15:05:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1056111    

Description Yedidyah Bar David 2013-12-30 21:57:27 UTC 
Description of problem:

dwh used to run as root. Since http://gerrit.ovirt.org/17311 it runs as 'ovirt'.

There are currently two different files with the database-access credentials:

# ls -l /etc/ovirt-engine/ovirt-engine-dwh/Default.properties /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf 
-rw-r--r--. 1 root root   80 Dec 30 16:37 /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
-rw-rw----. 1 root root 1075 Dec 30 16:36 /etc/ovirt-engine/ovirt-engine-dwh/Default.properties

so it does manage to read 10-setup-database.conf but not Default.properties . 10-setup-database.conf does not contain the database host, so with a remote database dwh fails to connect to the database.

Solution:
1. sync the spec with upstream - there, we have

%attr(-, %{engine_user}, %{engine_group}) %config(noreplace) %{_sysconfdir}/ovirt-engine/ovirt-engine-dwh/Default.properties

whereas downstream we have

%config(noreplace) %attr(-, %{engine_user}, %{engine_group}) %{_sysconfdir}/ovirt-engine/%{dwh_name}/Default.properties

I am not an expert in rpm spec files, but I guess "noreplace" affects only what's after it, so upstream will always change ownership but not content.

2. For better security, both files should be owned by root:ovirt with permissions 0640 - only root can read/write, only group ovirt can read (and not write).
Comment 1 Yedidyah Bar David 2013-12-30 22:14:51 UTC 
To reproduce:

1. install 3.2 with a remote database
2. upgrade to 3.3
3. Check /var/log/ovirt-engine/ovirt-engine-dwhd.log - you'll get lines line this:
2013-12-30 22:44:28|ykZvVa|ykZvVa|ykZvVa|OVIRT_ENGINE_DWH|HistoryETL|Default|6|Java Exception|tFileInputProperties_1|java.io.FileNotFoundException:/etc/ovirt-engine/ovirt-engine-dwh/Default
.properties (Permission denied)|1
org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.

(the second line is by dwh trying to connect to localhost)
Comment 2 Yedidyah Bar David 2014-01-01 11:06:12 UTC 
22797 makes these files owned by root:ovirt and perms 0640, read-only for ovirt and unreadable for everyone else.
Comment 4 Tareq Alayan 2014-01-16 14:05:51 UTC 
-rw-r-----. 1 root ovirt   83 Jan 16 15:48 /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
-rw-r-----. 1 root ovirt 1093 Jan 16 15:47 /etc/ovirt-engine/ovirt-engine-dwh/Default.properties

verified on rhevm-dwh-3.3.0-28.el6ev.noarch
Comment 6 errata-xmlrpc 2014-01-21 15:05:51 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2014-0036.html