Description
When a secret (likely affects configs too) is created from an environment variable and mounted into a container, according to the docs, they should have the UID/GID of the USER statement:
uid and gid: The numeric uid or gid that owns the file within /run/secrets/ in the service's task containers. Default value is USER.
However, unless explicitly specified, they will always belong to 0:0, aka. root.
It's irrelevant whether the service defines a user as well or not.
I would have expected them to have the UID/GID of the user that is running the image, since we've now faced permission denied errors when reading the secret files given that the user has no permission to read root files (since we adjust the mode to 440 or even 400).
Steps To Reproduce
- Create a folder
compose-secret-test
- Add the files listed below
- Run
docker compose up
- Check the output of the two containers
- Find that both list the secret
test-secret owner root:root
compose.yml
services:
test-build:
build:
context: .
dockerfile: Dockerfile
secrets:
- source: test-secret
mode: 0o440
test-image:
image: ubuntu:24.04
command: ["ls", "-al", "/run/secrets"]
user: "1000:1000"
secrets:
- source: test-secret
mode: 0o440
secrets:
test-secret:
environment: TEST_SECRET
Dockerfile
FROM ubuntu:24.04
USER 1000:1000
ENTRYPOINT [ "ls", "-al", "/run/secrets" ]
.env
TEST_SECRET=VerySecureSecret12345
Note: I chose ubuntu:24.04 as the example image because it has a user with UID/GID 1000 - even though that's not strictly necessary for this issue.
Compose Version
Docker Compose version v2.40.0
Docker Environment
Client: Docker Engine - Community
Version: 28.5.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.29.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.40.0
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 26
Running: 24
Paused: 0
Stopped: 2
Images: 28
Server Version: 28.5.1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: local
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
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: b98a3aace656320842a23f4a392a33f46af97866
runc version: v1.3.0-0-g4ca628d1
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-85-generic
Operating System: Ubuntu 24.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.5GiB
Name: <redacted>
ID: b30fcdfe-3673-432a-9a9b-2bba973e5bd0
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
Anything else?
No response
Description
When a secret (likely affects configs too) is created from an environment variable and mounted into a container, according to the docs, they should have the UID/GID of the
USERstatement:However, unless explicitly specified, they will always belong to
0:0, aka.root.It's irrelevant whether the service defines a
useras well or not.I would have expected them to have the UID/GID of the user that is running the image, since we've now faced permission denied errors when reading the secret files given that the user has no permission to read root files (since we adjust the mode to
440or even400).Steps To Reproduce
compose-secret-testdocker compose uptest-secretownerroot:rootcompose.ymlDockerfile.envNote: I chose
ubuntu:24.04as the example image because it has a user with UID/GID 1000 - even though that's not strictly necessary for this issue.Compose Version
Docker Environment
Anything else?
No response