Hide Forgot
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)
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....
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.
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)
Thanks.