--userns-remap causes shared mounts to also become slaves #36472
Comments
gvessere
changed the title
|
ping @kolyshkin @estesp PTAL |
|
Quick look at the source code doesn't reveal how this might happen; I will play with it more tomorrow |
|
@cpuguy83 maybe you have an idea? |
|
Are you sure the host mount point is just shared as well? IIRC this should be due to how the parent mount is propagated. |
|
step #3 in repro specifies the sharing status on the host folder:
yet still the mountpoint is mounted as a slave in the container... |
|
@gvessere What does |
|
I get the following:
dockerd runs as root, and I did have to run the --makeshared command with sudo (corrected in my original repro steps) |
|
@cpuguy83 my docker daemon runs as a "--userns-remap default" daemon. If I run the docker run command with host user namespace, things work as expected, the mountpoint is shared only and not also a slave:
so according to your statement, if the daemon and container are not running in the same user namespace then the mount point becomes a slave automatically, and this would be by design? |
|
Any update on this? I run dockerd with host $ mkdir /tmp/outside && chmod a+rwx /tmp/outside
host $ docker run -it --rm -v /tmp/outside:/outside:shared --security-opt apparmor:unconfined --cap-add SYS_ADMIN alpine:3.9
container # mkdir /outside/source /outside/target
container # mount --bind /outside/source /outside/target
container # echo foo > /outside/source/bar
host $ cat /tmp/outside/source/bar
foo
host $ cat /tmp/outside/target/bar
/bin/cat: /tmp/outside/target/bar: No such file or directoryWhen adding host $ docker run -it --rm -v /tmp/outside:/outside:shared --security-opt apparmor:unconfined --cap-add SYS_ADMIN --userns host alpine:3.9
container # mount --bind /outside/source /outside/target
host $ cat /tmp/outside/target/bar
fookernel 4.15.0-46-generic 49-Ubuntu |
$ systemctl show docker.service | grep -i mount
MountFlags=
MountAPIVFS=noSetting |
$ docker run --rm -v /tmp/outside:/outside:shared --userns host debian:stretch findmnt -o TARGET,PROPAGATION /outside
TARGET PROPAGATION
/outside shared
$ docker run --rm -v /tmp/outside:/outside:shared debian:stretch findmnt -o TARGET,PROPAGATION /outside
TARGET PROPAGATION
/outside shared,slaveIs this behavior intended? |
|
@gvessere, did you maybe find a fix or workaround for this issue? |
|
@cpuguy83 We're also hitting this issue trying to mount a directory as rshared inside a userns container, the mounts are always set as slaves. This is quite an old issue, should we assume this is a limitation of userns mode? |
|
I personally see the same behavior regardless of userns mode and mounts propagating back to the host as expected even with |
|
@cpuguy83 Are you doing remap on the daemon or container level? I'm not sure if it makes a difference but we're doing the remap on the daemon. |
the --userns-remap option only mounts shared mounts using the slave option. if the daemon is started without the userns-remap option, the container mountpoint is not a slave
Steps to reproduce the issue:
Describe the results you received:
...
shared,slave |-/containermount
...
Describe the results you expected:
...
shared |-/containermount
...
Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version:Output of
docker info:output of uname -a:
Linux ip-172-30-91-26 4.4.0-1052-aws #61-Ubuntu SMP Mon Feb 12 23:05:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: