Bug 1278414 - drop requirement of 'umask' argument on cpopen
Summary: drop requirement of 'umask' argument on cpopen
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: Core
Version: 4.17.10
Hardware: All
OS: All
low
low
Target Milestone: ovirt-4.0.0-alpha
: 4.18.0
Assignee: Francesco Romani
QA Contact: Petr Kubica
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-05 12:21 UTC by Francesco Romani
Modified: 2016-07-26 10:42 UTC (History)
4 users (show)

Fixed In Version: ovirt 4.0.0 alpha1
Clone Of:
Environment:
Last Closed: 2016-07-26 10:42:21 UTC
oVirt Team: Infra
Embargoed:
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
oourfali: devel_ack+
pstehlik: testing_ack+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 48133 0 master ABANDONED mkimage: lib: add and use umaskset helper Never
oVirt gerrit 48538 0 master MERGED mkimage: setup right permissions before mkisofs Never

Description Francesco Romani 2015-11-05 12:21:09 UTC 
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 18:21:22 UTC 
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 10:42:21 UTC 
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.