Bug 1483388

Summary:	libdm set umask(0177) and forget to restore old_umask on error
Product:	[Community] LVM and device-mapper	Reporter:	Youfu Zhang <zhangyoufu>
Component:	lvm2	Assignee:	Zdenek Kabelac <zkabelac>
lvm2 sub component:	libdevmapper	QA Contact:	cluster-qe <cluster-qe>
Status:	CLOSED NEXTRELEASE	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, zkabelac
Version:	unspecified	Flags:	rule-engine: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-23 04:44:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Youfu Zhang 2017-08-21 02:46:54 UTC

Description of problem:

File: libdm/ioctl/libdm-iface.c
Function: _create_control

old_umask is not restored when mknod failed

Actual results:
the umask is changed to 0177 and does not change back when mknod failed

Expected results:
the umask should be changed

Additional info:
I'm running docker nested in lxc container
dockerd tried devicemapper storage driver and failed, it chose vfs finally
But this bug changed umask and influenced permissions inside /var/lib/docker
This bug effectively stopped containers inside docker to change user (lost x permission on /, cannot access whole filesystem after setuid)

Comment 1 Zdenek Kabelac 2017-08-21 18:12:18 UTC

Sorry to spoil the game here - running  lvm2 INSIDE Docker container is simply invalid and totally unsupported AND unsupportable!

It can't work for long list of reason so there is no point in trying to run it.

But yep - it's possible the error path which effectively should never be trigger might need some care....

Comment 2 Youfu Zhang 2017-08-22 03:26:58 UTC

I'm not asking for anything unsupported here.

Docker has its own policy to choose storage driver in an unknown environment.
Docker's devicemapper driver is initialized and intended to fail in my situation.
But it shouldn't interfere the other parts - umask(0177) is a nightmare.

Comment 3 Zdenek Kabelac 2017-08-22 08:40:03 UTC

Should be addressed by this upstream commit:

https://www.redhat.com/archives/lvm-devel/2017-August/msg00064.html


But as said - none should ever try to use lvm2 INSIDE container - this is nothing else then pure bug of container usage  (as clearly  'DM' devices are not cgroup resource)

Comment 4 Youfu Zhang 2017-08-23 04:44:20 UTC

Thanks.