compose icon indicating copy to clipboard operation
compose copied to clipboard

restart changes tmpfs permission

Open gquintard opened this issue 3 years ago • 1 comments

Description

On restart, it looks like the permission of tmpfs volumes are changed.

Steps to reproduce the issue:

With this docker-compose.yaml:

version: '3.9'
services:
  varnish:
    image: "varnish:7.1"
    command: tail -f > /dev/null
    tmpfs:
      - "/var/lib/varnish/varnishd:exec"

run:

docker-compose up -d --force-recreate
docker-compose exec varnish ls -haltd /var/lib/varnish/varnishd/
docker-compose restart varnish
docker-compose exec varnish ls -haltd /var/lib/varnish/varnishd/

Describe the results you received:

the two ls commands will report two different permissions:

drwxrwxrwt 2 root root 40 Apr 25 01:08 /var/lib/varnish/varnishd/

and

drwxr-xr-x 2 root root 40 Apr 25 01:09 /var/lib/varnish/varnishd/

Describe the results you expected:

I'd have expected the permissions to stay the same.

Additional information you deem important (e.g. issue happens only occasionally):

It's systematic, and was first reported in https://github.com/varnish/docker-varnish/issues/53

Output of docker compose version:

Docker Compose version 2.4.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.1-docker)
  compose: Docker Compose (Docker Inc., 2.4.1)

Server:
 Containers: 5
  Running: 1
  Paused: 0
  Stopped: 4
 Images: 191
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  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 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: de8046a5501db9e0e478e1c10cbcfb21af4c6b2d.m
 runc version: 
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.17.4-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.645GiB
 Name: rayorn
 ID: WRGZ:HUZM:YFT7:RY66:2FFF:IKFV:FJBE:SLGU:FADG:A4Q4:EBO7:JUO6
 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

gquintard avatar Apr 25 '22 01:04 gquintard

bump?

gquintard avatar Sep 15 '22 16:09 gquintard

I just ran into this restart problem with nearly the exact same Varnish setup. I am very glad to find this issue and your originating issue replicating the problem. Huzzah that the temporary user: root fix exists but geez that's suboptimal lol. Thanks for chasing the issue @gquintard!

Smerity avatar Sep 25 '22 02:09 Smerity

Tagging docker/for-linux#138 here for context

nicksieger avatar Sep 27 '22 18:09 nicksieger

I can reproduce this, and I don't believe it's related to docker compose. At first glance it looks related to moby/moby#20437?

$ docker run -d --tmpfs /var/lib/varnish/varnishd:exec varnish:7.1 sh -c 'tail -f > /dev/null'
6e7d8214a5a04ce90f9895eeaaa06c15dd62215a60e0bd25ae00f1c66404ff76
$ docker exec 6e7 ls -haltd /var/lib/varnish/varnishd/
drwxrwxrwt 2 root root 40 Sep 27 20:08 /var/lib/varnish/varnishd/
$ docker restart 6e7
6e7
$ docker exec 6e7 ls -haltd /var/lib/varnish/varnishd/
drwxr-xr-x 2 root root 40 Sep 27 20:09 /var/lib/varnish/varnishd/

It looks like if you make sure the directory exists in your image with correct perms before launching the container, it will pick up those permissions on subsequent restarts.

$ cd /tmp
$ cat Dockerfile
# syntax:docker/dockerfile:1
FROM varnish:7.1
RUN mkdir -p -m 1777 /var/lib/varnish/varnishd
$ docker build -t myvarnish .
[+] Building 0.2s (6/6) FINISHED
 => [internal] load build definition from Dockerfile                                              0.0s
 => => transferring dockerfile: 134B                                                              0.0s
 => [internal] load .dockerignore                                                                 0.0s
 => => transferring context: 2B                                                                   0.0s
 => [internal] load metadata for docker.io/library/varnish:7.1                                    0.0s
 => [1/2] FROM docker.io/library/varnish:7.1                                                      0.0s
 => [2/2] RUN mkdir -p -m 1777 /var/lib/varnish/varnishd                                          0.1s
 => exporting to image                                                                            0.0s
 => => exporting layers                                                                           0.0s
 => => writing image sha256:9be45d72e419f9e3e55a11d2557467bd2df1e21a15c93fe9259ccc4b83258244      0.0s
 => => naming to docker.io/library/myvarnish                                                      0.0s
$ docker run -d --tmpfs /var/lib/varnish/varnishd:exec myvarnish sh -c 'tail -f > /dev/null'
ff94cf28dfd825aef6b03e50b86c9c6f0ac4fd03d92261b620d462e21db3b6f6
$ docker exec ff ls -haltd /var/lib/varnish/varnishd
drwxrwxrwt 2 root root 40 Sep 27 20:21 /var/lib/varnish/varnishd
$ docker restart ff
ff
$ docker exec ff ls -haltd /var/lib/varnish/varnishd
drwxrwxrwt 2 root root 40 Sep 27 20:22 /var/lib/varnish/varnishd

Going to go ahead and close this, please continue discussion on the moby issue if you want to lobby for a fix.

nicksieger avatar Sep 27 '22 20:09 nicksieger