Bug 1278414 – drop requirement of 'umask' argument on cpopen

Bug 1278414 - drop requirement of 'umask' argument on cpopen

Summary:	drop requirement of 'umask' argument on cpopen

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	vdsm
Classification:	oVirt
Component:	Core (Show other bugs)
Sub Component:
Version:	4.17.10
Hardware:	All All

Priority	low Severity low (vote)
Target Milestone:	ovirt-4.0.0-alpha
Target Release:	4.18.0
Assigned To:	Francesco Romani
QA Contact:	Petr Kubica
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2015-11-05 07:21 EST by Francesco Romani
Modified:	2016-07-26 06:42 EDT (History)
CC List:	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:	---

Flags:	rule-engine: ovirt‑4.0.0+ rule-engine: planning_ack+ oourfali: devel_ack+ pstehlik: testing_ack+

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

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

Groups: 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.