Permissions are not specific in tmpfs subdirectory of volume directory

[Kwadz]

Let's assume this docker-compose.yml:

version: '3'

services:
  website:
    build:
      context: .
      dockerfile: ./.docker/php/Dockerfile
    volumes:
      - .:/var/www/html/
    tmpfs:
      - /var/www/html/app/cache/

Expected behaviour: the permissions of /var/www/html/app/cache/ should be 1777 (the default for tmpfs-mode).

Actual behavior: the permissions of /var/www/html/app/cache/ is overridden by the permissions of /var/www/html/

This feature could help a lot about performance, by defining the cache directory of a project as a tmpfs volume.

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[Kwadz]

I think fixing this issue would also fix some performance issues encountered with projects like Symfony.

[thaJeztah]

I'm trying to reproduce the issue to see if it's specific to docker for mac, and if setting a different mode for the tmpfs would work

I tried this on a Ubuntu 18.04 node, with docker 19.03;

`docker version`

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b7f0
 Built:             Wed Mar 11 01:25:46 2020
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:24:19 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

`docker info`

Client:
  Debug Mode: false
  Plugins:
   app: Docker Application (Docker Inc., v0.8.0)
   buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
 
 Server:
  Containers: 6
   Running: 1
   Paused: 0
   Stopped: 5
  Images: 15
  Server Version: 19.03.8
  Storage Driver: overlay2
   Backing Filesystem: <unknown>
   Supports d_type: true
   Native Overlay Diff: true
  Logging Driver: json-file
  Cgroup Driver: cgroupfs
  Plugins:
   Volume: local
   Network: bridge host ipvlan macvlan null overlay
   Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
  Swarm: active
   NodeID: yg550ettvsjn6g6t840iaiwgb
   Is Manager: true
   ClusterID: abajmipo7b4xz5ip2nrla6b11
   Managers: 3
   Nodes: 4
   Default Address Pool: 10.0.0.0/8
   SubnetSize: 24
   Data Path Port: 4789
   Orchestration:
    Task History Retention Limit: 5
   Raft:
    Snapshot Interval: 10000
    Number of Old Snapshots to Retain: 0
    Heartbeat Tick: 1
    Election Tick: 3
   Dispatcher:
    Heartbeat Period: 5 seconds
   CA Configuration:
    Expiry Duration: 3 months
    Force Rotate: 0
   Autolock Managers: false
   Root Rotation In Progress: false
   Node Address: 10.133.83.180
   Manager Addresses:
    10.133.77.81:2377
    10.133.79.16:2377
    10.133.83.180:2377
  Runtimes: runc
  Default Runtime: runc
  Init Binary: docker-init
  containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
  runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
  init version: fec3683
  Security Options:
   apparmor
   seccomp
    Profile: default
  Kernel Version: 4.15.0-99-generic
  Operating System: Ubuntu 18.04.1 LTS
  OSType: linux
  Architecture: x86_64
  CPUs: 1
  Total Memory: 985.2MiB
  Name: swarm-test-01
  ID: PMN6:XK6Z:G7QC:A3C5:4F7Z:FPUG:Q63Q:DWZQ:HQKU:BHYQ:ELR7:3TDM
  Docker Root Dir: /var/lib/docker
  Debug Mode: true
   File Descriptors: 42
   Goroutines: 139
   System Time: 2020-05-01T11:04:45.893736023Z
   EventsListeners: 0
  Username: thajeztah
  Registry: https://index.docker.io/v1/
  Labels:
  Experimental: false
  Insecure Registries:
   127.0.0.0/8
  Live Restore Enabled: false

These are the steps I performed:

With an empty directory

mkdir testperms && cd testperms

created this compose file;

version: '3'

services:
  website:
    image: nginx:alpine
    volumes:
      - .:/usr/share/nginx/html/
    tmpfs:
      - /usr/share/nginx/html/app/cache/

Deployed the compose file;

docker-compose up -d

Creating network "testperms_default" with the default driver
Creating testperms_website_1 ... done

Checked the mounts inside the container;

docker exec -it testperms_website_1 sh -c 'mount | grep html'

/dev/vda1 on /usr/share/nginx/html type ext4 (rw,relatime,data=ordered)
tmpfs on /usr/share/nginx/html/app/cache type tmpfs (rw,nosuid,nodev,noexec,relatime)

Checked the permissions of both /usr/share/nginx/html/ and /usr/share/nginx/html/app/cache/

docker exec -it testperms_website_1 sh -c "stat -c '%a %n' usr/share/nginx/html/ && stat -c '%a %n' usr/share/nginx/html/app/cache/"

755 usr/share/nginx/html/
1777 usr/share/nginx/html/app/cache/

Remove the compose stack

docker-compose down -v

After the compose stack has run, files were created in the local directory (linux needs a mount-point, and given that the local directory was bind-mounted on /usr/share/nginx/html, an app/cache/ directory was created as mount-point for the tmpfs

tree
.
├── app
│   └── cache
└── docker-compose.yaml

Second run (app/cache exists on host)

Trying to see if the tmpfs inherits the permissions of that directory if it exists;

docker-compose up -d

This time the permissions are different indeed;

docker exec -it testperms_website_1 sh -c "stat -c '%a %n' usr/share/nginx/html/ && stat -c '%a %n' usr/share/nginx/html/app/cache/"

755 usr/share/nginx/html/
755 usr/share/nginx/html/app/cache/

Trying with explicit tmpfs-mode

Perhaps the mode for the tmpfs would make a difference; this option is supported on docker run (using the --mount flag), but not yet in docker-compose;
this issue was tracking that (for the compose schema and docker stack deploy): docker/cli#698, and this pr "mentions" tmpfs-mode,
but only implemented tmpfs-size: docker/cli#808

Trying with docker run and explicitly setting mode to 1777:

docker run -d --rm --name webtest \
    --mount type=bind,source=$(pwd),target=/usr/share/nginx/html/ \
    --mount type=tmpfs,target=/usr/share/nginx/html/app/cache,tmpfs-mode=1777 \
    nginx:alpine

Doesn't seem to make a difference:

docker exec -it webtest sh -c "stat -c '%a %n' usr/share/nginx/html/ && stat -c '%a %n' usr/share/nginx/html/app/cache/"

755 usr/share/nginx/html/
755 usr/share/nginx/html/app/cache/

Trying a difference mode (1700):

docker rm -fv webtest
docker run -d --rm --name webtest \
    --mount type=bind,source=$(pwd),target=/usr/share/nginx/html/ \
    --mount type=tmpfs,target=/usr/share/nginx/html/app/cache,tmpfs-mode=1700 \
    nginx:alpine

And checking the mode for the mount;

docker exec -it webtest sh -c 'mount | grep html'

/dev/vda1 on /usr/share/nginx/html type ext4 (rw,relatime,data=ordered)
tmpfs on /usr/share/nginx/html/app/cache type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=1700)

But that doesn't look to have any effect:

docker exec -it webtest sh -c "stat -c '%a %n' usr/share/nginx/html/ && stat -c '%a %n' usr/share/nginx/html/app/cache/"

755 usr/share/nginx/html/
755 usr/share/nginx/html/app/cache/

Trying on the host

Let's try the same situation on the host

docker-compose down -v
docker rm -fv webtest

mkdir -p host/html/app/cache container/html/app/cache
chmod -R 755 host container

mount --make-private container/html

Create a "container"; bind-mount the host host/html onto container/html, and mount a tmpfs on container/html/app/cache

mount -t none -o bind host/html container/html
mount -t tmpfs -o rw,nosuid,nodev,noexec,relatime,mode=1777 tmpfs container/html/app/cache

Check mounts

mount | grep container/html
/dev/vda1 on /root/testperms/container/html type ext4 (rw,relatime,data=ordered)
tmpfs on /root/testperms/container/html/app/cache type tmpfs (rw,nosuid,nodev,noexec,relatime)

Checking permissions, this time the mode does take effect:

stat -c '%a %n' container/html && stat -c '%a %n' container/html/app/cache

755 container/html
1777 container/html/app/cache

trying on the host, with mode=1700

Unmount the previous mounts

umount container/html/app/cache container/html

Create the mounts again, this time with mode=1700

mount -t none -o bind host/html container/html
mount -t tmpfs -o rw,nosuid,nodev,noexec,relatime,mode=1700 tmpfs container/html/app/cache

Check mounts

mount | grep container/html
/dev/vda1 on /root/testperms/container/html type ext4 (rw,relatime,data=ordered)
tmpfs on /root/testperms/container/html/app/cache type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=1700)

Checking permissions:

stat -c '%a %n' container/html && stat -c '%a %n' container/html/app/cache

755 container/html
1700 container/html/app/cache

[thaJeztah]

Testing with an pre-existing mount-point in the container

docker build -t testimage -<<EOF
FROM nginx:alpine
RUN mkdir -p /usr/share/nginx/html/app/cache/ && chmod 755 /usr/share/nginx/html/app/cache/
EOF

Using mode 1700 directly here

docker rm -fv webtest
docker run -d --rm --name webtest \
    --mount type=tmpfs,target=/usr/share/nginx/html/app/cache,tmpfs-mode=1700 \
    testimage

Checking mounts;

docker exec -it webtest sh -c 'mount | grep html'

tmpfs on /usr/share/nginx/html/app/cache type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=1700)

Checking permissions:

docker exec -it webtest sh -c "stat -c '%a %n' /usr/share/nginx/html/ && stat -c '%a %n' /usr/share/nginx/html/app/cache/"

755 /usr/share/nginx/html/
755 /usr/share/nginx/html/app/cache/

So in this case, permissions are also inherited from the existing mount-point.

(edited: see below)

[thaJeztah]

From the above, it looks like it's not specific to Docker for Mac (and probably a ticket should be opened in https://github.com/moby/moby). I'm not sure at this point what's the reason for this 🤔

Let me open a ticket in moby/moby for discussion, perhaps someone has an idea

[thaJeztah]

Actually; ignore my comment about nested mounts; I forgot that the app/cache directory is not present in the nginx image, so the difference is not with the other mount but if the app/cache directory is pre-existing.

I'll edit my comment above

[thaJeztah]

opened moby/moby#40881

[khimaros]

This will not work for all cases but, for some, you can use the undocumented uid= and gid= parameters to workaround.