Bug 1613402

Summary: Usage of sed -i in the dbscripts creates temporary files inside the directory
Product: [oVirt] ovirt-engine Reporter: Benny Zlotnik <bzlotnik>
Component: Packaging.rpmAssignee: Yedidyah Bar David <didi>
Status: CLOSED CURRENTRELEASE QA Contact: Lucie Leistnerova <lleistne>
Severity: low Docs Contact:
Priority: low    
Version: ---CC: bugs, bzlotnik, lleistne
Target Milestone: ovirt-4.3.1Flags: rule-engine: ovirt-4.3+
lleistne: testing_ack+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.3.1.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-13 16:39:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Benny Zlotnik 2018-08-07 13:50:15 UTC
Description of problem:
dbfunc-custom.sh runs `sed -i` on multiple occasions, for instance:
	sed -i "s/'${spid}'/'${gen_spid}'/g" "${DBFUNC_COMMON_DBSCRIPTS_DIR}"/data/*.sql
	sed -i "s/'${clusterid}'/'${gen_clusterid}'/g" "${DBFUNC_COMMON_DBSCRIPTS_DIR}"/data/*.sql

This causes the creation of a temporary file inside the ${DBFUNC_COMMON_DBSCRIPTS_DIR}
and will fail when run by a non-privileged user outside of the engine-setup context, for instance: 
https://gerrit.ovirt.org/#/c/92842/8/packaging/bin/engine-config-diff.sh

will fail with: "sed: couldn't open temporary file /usr/share/ovirt-engine/dbscripts/data/sed9aIFYv: Permission denied"

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Sandro Bonazzola 2018-08-08 11:17:33 UTC
(In reply to Benny Zlotnik from comment #0)
> Description of problem:
> dbfunc-custom.sh runs `sed -i` on multiple occasions, for instance:
> 	sed -i "s/'${spid}'/'${gen_spid}'/g"
> "${DBFUNC_COMMON_DBSCRIPTS_DIR}"/data/*.sql
> 	sed -i "s/'${clusterid}'/'${gen_clusterid}'/g"
> "${DBFUNC_COMMON_DBSCRIPTS_DIR}"/data/*.sql
> 
> This causes the creation of a temporary file inside the
> ${DBFUNC_COMMON_DBSCRIPTS_DIR}
> and will fail when run by a non-privileged user outside of the engine-setup
> context, for instance: 
> https://gerrit.ovirt.org/#/c/92842/8/packaging/bin/engine-config-diff.sh
> 
> will fail with: "sed: couldn't open temporary file
> /usr/share/ovirt-engine/dbscripts/data/sed9aIFYv: Permission denied"

How is this a problem? Do you think we should allow unprivileged user to access engine database?

Comment 2 Benny Zlotnik 2018-08-08 14:15:14 UTC
> How is this a problem? Do you think we should allow unprivileged user to
> access engine database?

I was asked to create this bug by Didi, the issue being temporary files created not in /tmp

I needed to run schema.sh from my tool to create the engine database on another instance, and I was able to work around this issue by copying the entire dbscripts directory to /tmp

Comment 3 Yedidyah Bar David 2018-08-13 08:08:27 UTC
Having a read-only /usr is considered a good thing, and while Fedora guidelines do not require this, they do want to allow having this, as much as possible. See also:

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://gerrit.ovirt.org/16366
https://gerrit.ovirt.org/23794

IMO we should also, after we fix current bug, add code to OST (or just check-patch) to prevent such future cases.

Comment 4 Sandro Bonazzola 2019-01-21 08:28:29 UTC
re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0.
If you think this bug should block 4.3.0 please re-target and set blocker flag.

Comment 5 Sandro Bonazzola 2019-01-30 09:18:38 UTC
Let's check if STIG is affected.

Comment 6 Yedidyah Bar David 2019-02-13 09:31:13 UTC
QE: Not sure what's the best way to test current bug.

If all you want is to make sure only what's in the description was fixed, you can check (ls -l) the files under /usr/share/ovirt-engine/dbscripts/data , compared with other files from that package (e.g. in /usr/share/ovirt-engine/dbscripts ), after running engine-setup. With broken version, you'll see that the timestamp of the files in data/ is different, newer, the time of running engine-setup, whereas the timestamp of the other files will be the time the package was last upgraded. Since normal upgrades also update the package, it will be a bit hard to test - so either test by running again engine-setup when there are no more updates, or run it with --offline.

If you want a more thorough test, you should probably find means to mount /usr read-only, perhaps that's documented somewhere, not sure, and add config/hooks/something that mounts it read-write only during rpm/yum runs. Then, ideally, engine-setup should still succeed. If it does not, and it's not due to current bug, please open new ones as needed.

Comment 7 Lucie Leistnerova 2019-03-04 15:01:00 UTC
There is no date change compared to package install in /usr/share/ovirt-engine/dbscripts after installing new engine or updating.

verified in ovirt-engine-4.3.1.1-0.1.el7.noarch

When there will be similar issue in other tool, please open new BZ.

Comment 8 Sandro Bonazzola 2019-03-13 16:39:29 UTC
This bugzilla is included in oVirt 4.3.1 release, published on February 28th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.1 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.