Bug 1278414 - drop requirement of 'umask' argument on cpopen
drop requirement of 'umask' argument on cpopen
Status: CLOSED CURRENTRELEASE
Product: vdsm
Classification: oVirt
Component: Core (Show other bugs)
4.17.10
All All
low Severity low (vote)
: ovirt-4.0.0-alpha
: 4.18.0
Assigned To: Francesco Romani
Petr Kubica
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-05 07:21 EST by Francesco Romani
Modified: 2016-07-26 06:42 EDT (History)
4 users (show)

See Also:
Fixed In Version: ovirt 4.0.0 alpha1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-26 06:42:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.0.0+
rule-engine: planning_ack+
oourfali: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 48133 master ABANDONED mkimage: lib: add and use umaskset helper Never
oVirt gerrit 48538 master MERGED mkimage: setup right permissions before mkisofs Never

  None (edit)
Description Francesco Romani 2015-11-05 07:21:09 EST
Description of problem:
VDSM leverages the 'umask' argument of cpopen to make sure some image it creates have the right permissions right from the start, so possibly sensitive information from the images does not leak.

We want to make cpopen API identical to standard subprocess one, so we should find a different way to run the same command without the 'umask' argument, so we can drop it from cpopen


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

How reproducible:
100%
Comment 1 Francesco Romani 2015-12-08 13:21:22 EST
The fix will be completely transparent to any user flow, otherwise it's a regression (!).

To test this change, trigger any flow which requires VDSM to build an ISO image on the fly, for example run a VM with cloud-init, or sysprep.
VM should run as usual. The newly-created image will be located under /var/run/vdsm/payload and should not be world-readable.
Comment 2 Lukas Svaty 2016-07-26 06:42:21 EDT
This bug was fixed and is slated to be in the upcoming version. As we
are focusing our testing at this phase on severe bugs, this bug was
closed without going through its verification step. If you think this
bug should be verified by QE, please set its severity to high and move
it back to ON_QA

Note You need to log in before you can comment on or make changes to this bug.