tmpfs mount’s mode inconsistency

Description

Running a container with a tmpfs bind mount more than once gives different modes (permissions) for the mount.

Reproduce

$ docker run --name tmpfs-test --mount type=tmpfs,destination=/test --user 65534:65534 busybox:uclibc ls -adhl /test
drwxrwxrwt    2 root     root          40 May 17 10:28 /test
$ docker start --attach tmpfs-test
drwxr-xr-x    2 root     root          40 May 17 10:28 /test

Expected behavior

The first time the tmpfs bind mount has a drwxrwxrwt mode (great!), but the second time (and subsequent times) it has a drwxr-xr-x mode, i.e. group and others lost their write permission. I expected to get the same permission every time.

And with no way of specifying the mode (correct me if I’m wrong) I’d prefer having the more generous permissions for a tmpfs mount (especially when running the container non-root).

docker version

Client: Docker Engine - Community
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:28:22 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          23.0.5
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.19.8
  Git commit:       94d3ad6
  Built:            Wed Apr 26 16:17:45 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.20
  GitCommit:        2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc:
  Version:          1.1.5
  GitCommit:        v1.1.5-0-gf19387a
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.17.3)
  scan: Docker Scan (Docker Inc., v0.23.0)

Server:
 Containers: 4
  Running: 2
  Paused: 0
  Stopped: 2
 Images: 4
 Server Version: 23.0.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc version: v1.1.5-0-gf19387a
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.10.0-18-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.4GiB
 Name: enterprise
 ID: BQWZ:PUSP:OPHV:UC3T:3SVS:SFKH:OJPD:A5CO:NDHN:76DJ:WLGP:S5G5
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

This was first reported as a bug in Docker Compose (docker/compose#10477) but deemed not to be Compose-specific.

Start with the reported docker run and docker start --attach reproduction for a tmpfs mount using BusyBox and user 65534:65534. Trace the tmpfs mount lifecycle across the initial create and subsequent start, then verify that /test retains the same permissions on every run. Check the linked Compose report for context about the behavior being Docker-specific.