tmpfs permissions confusion

[sergeev917]

The thought below is spanning across both docker and runc. In case I should be addressing the issue somewhere else, please let me know.

I find a bit confusing how tmpfs mounts are implemented. Simply doing

docker run --mount type=tmpfs,destination=some-path-here,tmpfs-mode=1770 <...>

will produce variable outcome when the mount point already exists and when it doesn't. That is, the tmpfs-mode argument is effectively ignored when the mountpoint exists, since the mode is copied back from the destination directory (libcontainer/rootfs_linux.go:190).

Well, being familiar with this behaviour now, I think this might be useful (still I found nothing about this in docs: https://docs.docker.com/engine/admin/volumes/tmpfs/).

But why then uid/gid are not restored as well? Mounting a tmpfs over the existing directory will preserve mode bits, but replace uid and gid with root. So runc is stopping somewhere in between -- it does neither fully restore permissions from the existing mount point nor rely on tmpfs mount options (uid, gid, mode, etc). Can this be resolved into a fully consistent behaviour?

[cyphar]

Yeah, we should probably also preserve the owner information. I'll write up a patch. Though you /could/ argue it's a partial security issue as an image could make the owner an unprivileged user to try to trick the container runtime to make the owner of the mount something different...

[margana]

Also got bitten by this issue, personally I would expect tmpfs-mode to be honoured when specified

[struanb]

Hello. This issue seems potentially related to Permissions on tmpfs mounts reset after container restart and --tmpfs with --user works for the first time. Fails in subsequent container starts.

Right now, I'm not sure there is a way to use --mount=tmpfs to mount a tmpfs that is still writeable by a non-root user after a container restart, unless the underlying mountpoint has o+rwx permissions. (I think it can be done with --tmpfs=/tmp2 as, although the specified mode does not survive a container restart, the specified uid does).