[BUG] Secrets (likely configs too) have incorrect uid/gid

[ffried]

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

1. Create a folder compose-secret-test
2. Add the files listed below
3. Run docker compose up
4. Check the output of the two containers
5. 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

[ndeloof]

Unfortunately my fix is incorrect and triggered #13296
secrets and configs were introduced in the compose file format for Docker Swarm and compose spec was created from those legacy docs, but the described behavior can't be implemented by Docker Compose as Docker engine doesn't offer the required APIs. I'll update the spec accordingly