Bug 1483388 - libdm set umask(0177) and forget to restore old_umask on error
Summary: libdm set umask(0177) and forget to restore old_umask on error
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: unspecified
Hardware: All
OS: All
Target Milestone: ---
: ---
Assignee: Zdenek Kabelac
QA Contact: cluster-qe@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2017-08-21 02:46 UTC by Youfu Zhang
Modified: 2017-08-23 04:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-23 04:44:20 UTC
rule-engine: lvm-technical-solution?
rule-engine: lvm-test-coverage?

Attachments (Terms of Use)

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:


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

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