[BUG] Secret has bad ownership and permission mode when created with the contents of the file

[lesha-filimonov]

Description

According to the documentation:

Default value [Author's note: the value of owner UID or GID] is USER running container.

The default value [Author's note: the value of permissions] is world-readable permissions (mode 0444).

However, file was mounted in /run/secrets/ saves ownership and permission mode from host filesystem.

Steps To Reproduce

Initial State

• project folder

$ ls -l
total 8
-rw-r--r-- 1 hostuser hostuser 170 Dec  9 10:00 docker-compose.yaml
-rw------- 1 hostuser hostuser 17  Dec  9 09:51 secret.txt

• docker-compose.yaml

services:
  app:
    image: alpine:3.14
    user: root:root # did not necessarily, just for clarity
    command: ls -l /run/secrets/secret # output of this command demonstrate the issue
    secrets:
      - secret

secrets:
  secret:
    file: ./secret.txt

• Current user

$ id
uid=1000(hostuser) gid=1000(hostuser) groups=1000(hostuser),27(sudo),100(hostuser),109(docker)

Reproduction issue

$ docker compose up
[+] Running 1/0
 ✔ Container docker-secrets-app-1  Created                                                                         0.0s
Attaching to app-1
app-1  | -rw-------    1 1000     1000            17 Dec  9 08:51 /run/secrets/secret
app-1 exited with code 0

Conclusion

• Expected

app-1  | -r--r--r--    1 root     root            17 Dec  9 08:51 /run/secrets/secret

• Obtained

app-1  | -rw-------    1 1000     1000            17 Dec  9 08:51 /run/secrets/secret

Compose Version

Docker Compose version v2.29.7

Docker Environment

Client: Docker Engine - Community
 Version:    27.3.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.17.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.7
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 8
 Server Version: 27.3.1
 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 splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 88bf19b2105c8b17560993bee28a01ddc2f97182
 runc version: v1.2.2-0-g7cb3632
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.0-28-amd64
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 1.921GiB
 Name: volatile-song.aeza.network
 ID: 5213dc93-ca9d-4af2-844c-29b2712b1232
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Anything else?

If you run docker compose up as root, the same result will be obtained.

[ndeloof]

This is a known limitation: Secrets defined by a file are actually bind-mounted inside container and there's no mechanism to allow changing ownership

Also see #12251 which could provide a fix for this issue