Hide Forgot
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:
(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?
> 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
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.
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.
Let's check if STIG is affected.
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.
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.
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.