Description of problem: When running docker with --userns-remap=default you cannot run any container because it fails with operation not permitted. Version-Release number of selected component (if applicable): docker-1.10.2-7.git0f5ac89.fc25.x86_64 How reproducible: always Steps to Reproduce: 1. edit /etc/sysconfig/docker and add "--userns-remap=default" to OPTIONS= 2. restart docker 3. docker run -ti busybox sh Actual results: # docker run -ti busybox sh [ 75.439881] XFS (dm-1): Mounting V5 Filesystem [ 75.456044] XFS (dm-1): Ending clean mount [ 75.497973] XFS (dm-1): Unmounting Filesystem [ 75.595390] XFS (dm-1): Mounting V5 Filesystem [ 75.603515] XFS (dm-1): Ending clean mount [ 75.637471] XFS (dm-1): Unmounting Filesystem [ 75.718502] XFS (dm-1): Mounting V5 Filesystem [ 75.723190] XFS (dm-1): Ending clean mount [ 75.737871] device veth193533b entered promiscuous mode [ 75.738881] IPv6: ADDRCONF(NETDEV_UP): veth193533b: link is not ready [ 75.798620] eth0: renamed from veth00288c7 [ 75.802720] IPv6: ADDRCONF(NETDEV_CHANGE): veth193533b: link becomes ready [ 75.803685] docker0: port 1(veth193533b) entered forwarding state [ 75.804474] docker0: port 1(veth193533b) entered forwarding state [ 75.816990] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue) Timestamp: 2016-02-28 10:49:36.639595591 -0500 EST Code: System error Message: operation not permitted Frames: --- 0: setupRootfs Package: github.com/opencontainers/runc/libcontainer File: rootfs_linux.go@40 --- 1: Init Package: github.com/opencontainers/runc/libcontainer.(*linuxStandardInit) File: standard_init_linux.go@57 --- 2: StartInitialization Package: github.com/opencontainers/runc/libcontainer.(*LinuxFactory) File: factory_linux.go@240 --- 3: initializer Package: github.com/docker/docker/daemon/execdriver/native File: init.go@35 --- 4: Init Package: github.com/docker/docker/pkg/reexec File: reexec.go@26 --- 5: main Package: main File: docker.go@18 --- 6: main Package: runtime File: proc.go@188 --- 7: goexit Package: runtime File: asm_amd64.s@1998 [ 75.853474] veth00288c7: renamed from eth0 [ 75.863623] docker0: port 1(veth193533b) entered disabled state [ 75.895627] docker0: port 1(veth193533b) entered disabled state [ 75.897667] device veth193533b left promiscuous mode [ 75.898302] docker0: port 1(veth193533b) entered disabled state [ 75.982317] XFS (dm-1): Unmounting Filesystem docker: Error response from daemon: Cannot start container 55d634a3355b5036d048cdd0cd09d96a3b98b9af395ed762c740d356157f8053: [9] System error: operation not permitted. Expected results: docker runs fine Additional info: not sure if it's related but this seems the cause of the operation not supported: SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue) if you remove --selinux-enabled from the daemon options everything runs fine
This bug is also present in the current 1.10.x version we'd like to ship to f23 which is in updates-testing
What AVC's are you seeing. ausearch -m avc -ts recent
$ ausearch -m avc -ts recent ---- time->Mon Feb 29 10:02:39 2016 type=AVC msg=audit(1456758159.888:355): avc: denied { getattr } for pid=3002 comm="ls" path="/dev/fuse" dev="devtmpfs" ino=13993 scontext=system_u:system_r:svirt_lxc_net_t:s0:c280,c1010 tcontext=system_u:object_r:fuse_device_t:s0 tclass=chr_file permissive=0 ---- time->Mon Feb 29 10:04:54 2016 type=AVC msg=audit(1456758294.444:429): avc: denied { create } for pid=3417 comm="systemd-user-se" name=".#nologinPQgyBA" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=file permissive=0 ---- time->Mon Feb 29 10:05:13 2016 type=AVC msg=audit(1456758313.361:264): avc: denied { create } for pid=1016 comm="systemd-user-se" name=".#nologin8D85lp" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=file permissive=0 ----- Are those related? I got those after I did docker run -ti busybox sh Also: docker run -ti -v /dev/mqueue:/dev/mqueue busybox sh seems to be working
also bind-mounting dev mqueue from the host seems to have the correct ownership: drwxrwxrwt 2 65534 65534 40 Feb 29 15:05 mqueue I'm not sure this is right
setenforce 0 Does it only give you the fusefs error? Does user namespace use /dev/fuse? This seems to be a new file system in the os. We can add the ability for svirt_lxc_net_t to use them
alright setenforce 0 doesn't change the situation here, the only thing which makes this work is removing --selinux-enabled from the daemon OPTION= in /etc/sysconfig/docker - not sure what's happening, I'll try to debug it WRT /dev/fuse - yes it seems a new fs in rawhide, we can add svirt_lxc_net_t so ppl can use it
This dmesg message may be helpful though: [ 75.816990] SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
That is actually hanlded currently, but not for /dev/fuse. Is /dev/fuse something new for docker-1.11?
(In reply to Daniel Walsh from comment #8) > That is actually hanlded currently, but not for /dev/fuse. Is /dev/fuse > something new for docker-1.11? I don't think so, I do have to check but I doubt. still, why the selinux-flag is causing this? I spin up another rawhide vm and ausearch output is empty.
If it is breaking, add semodule -DB setenforce 0 Run docker tests setenforce 1 semdodule -B And attach the avcs. Really only looking at svirt_lxc_net_t ones.
This has been also reported upstream https://github.com/docker/docker/issues/20798
will be fixed in docker 1.11 as per upstream issue https://github.com/docker/docker/issues/20798
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.