Only root user has access to the secret

[gurmit456]

My docker compose file looks like below:

rabbitmq:
   image: rabbitmq:latest
   volumes: 
     - type: volume
       source: rabbit_mq_data
       target: /var/lib/rabbitmq
   secrets:
     -  source: rabbitmq_private_cert_key.pem
        mode: 0444
     -  source: rabbitmq_cert.pem
        mode: 0444
     -  source: rabbitmq_root_ca.pem
        mode: 0444

And when I look at the mounted secrets in running container the permission looks like below:

ls -l /run/secrets/
total 16
-rw-r--r-- 1 1000 1000 1931 Jan  7 11:52 rabbitmq_cert.pem
-rw------- 1 1000 1000 5174 Jan  7 19:19 rabbitmq_private_cert_key.pem
-rw-r--r-- 1 1000 1000 1960 Jan  6 18:43 rabbitmq_root_ca.pem

For secret- rabbitmq_private_cert_key.pem only root user has read access. I’m not able understand why docker is giving different permission to a specific secret? Mode value does not seems to have any impact on mounted secret file.
My docker version is: 20.10.1
I’ll appreciate any help.

[meyay (Metin Y.)]

The long syntax is not supported during docker-compose deployments. You should have received a warning per secret… With docker-compose the mode of each file on the host will be retained. The long syntax works as expected with docker swarm (=docker stack deploy) deployments.

Example docker-compose.yml:

version: '3.6'

secrets:
   secret777:
     file: "./secret.txt"
   secret666:
     file: "./secret.txt"
   secret644:
     file: "./secret.txt"
   secret444:
     file: "./secret.txt"
   secret400:
     file: "./secret.txt"

services:
   ubuntu:
     image: ubuntu:18.04
     deploy:
      restart_policy:
        condition: none
     secrets:
     - source: secret777
       target: /custom/path/secret777.txt
       uid: '1000'
       gid: '1000'
       mode: 0777
     - source: secret666
       target: /custom/path/secret666.txt
       uid: '1000'
       gid: '1000'
       mode: 0666
     - source: secret644
       target: /custom/path/secret644.txt
       uid: '1000'
       gid: '1000'
       mode: 0644
     - source: secret444
       target: /custom/path/secret444.txt
       uid: '1000'
       gid: '1000'
       mode: 0444
     - source: secret400
       target: /custom/path/secret400.txt
       uid: '1000'
       gid: '1000'
       mode: 0400
     command: ls -l /custom/path

Steps to test:

echo "topsecret" > secret.txt
docker stack deploy -c docker-compose.yml secret
docker service logs  secret_ubuntu
docker stack rm secret

Output of service logs:

me@swarm1:~/secrets$ docker service logs secret_ubuntu
secret_ubuntu.1.urtnv80wfmn2@swarm3 | total 20
secret_ubuntu.1.urtnv80wfmn2@swarm3 | -r-------- 1 1000 1000 5 Jan 7 22:15 secret400.txt
secret_ubuntu.1.urtnv80wfmn2@swarm3 | -r–r--r-- 1 1000 1000 5 Jan 7 22:15 secret444.txt
secret_ubuntu.1.urtnv80wfmn2@swarm3 | -rw-r–r-- 1 1000 1000 5 Jan 7 22:15 secret644.txt
secret_ubuntu.1.urtnv80wfmn2@swarm3 | -rw-rw-rw- 1 1000 1000 5 Jan 7 22:15 secret666.txt
secret_ubuntu.1.urtnv80wfmn2@swarm3 | -rwxrwxrwx 1 1000 1000 5 Jan 7 22:15 secret777.txt

If you use docker-compose up instead, the output will look like this:

me@swarm1:~/secrets$ docker-compose up
WARNING: Service “ubuntu” uses secret “secret777” with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: Service “ubuntu” uses secret “secret666” with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: Service “ubuntu” uses secret “secret644” with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: Service “ubuntu” uses secret “secret444” with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: Service “ubuntu” uses secret “secret400” with uid, gid, or mode. These fields are not supported by this implementation of the Compose file
WARNING: The Docker Engine you’re using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use docker stack deploy.

Creating network “secrets_default” with the default driver
Pulling ubuntu (ubuntu:18.04)…
18.04: Pulling from library/ubuntu
Digest: sha256:fd25e706f3dea2a5ff705dbc3353cf37f08307798f3e360a13e9385840f73fb3
Status: Downloaded newer image for ubuntu:18.04
Creating secrets_ubuntu_1 … done
Attaching to secrets_ubuntu_1
ubuntu_1 | total 20
ubuntu_1 | -rw-rw-r-- 1 1001 1001 5 Jan 7 19:46 secret400.txt
ubuntu_1 | -rw-rw-r-- 1 1001 1001 5 Jan 7 19:46 secret444.txt
ubuntu_1 | -rw-rw-r-- 1 1001 1001 5 Jan 7 19:46 secret644.txt
ubuntu_1 | -rw-rw-r-- 1 1001 1001 5 Jan 7 19:46 secret666.txt
ubuntu_1 | -rw-rw-r-- 1 1001 1001 5 Jan 7 19:46 secret777.txt

the output of ls -l:

me@swarm1:~/secrets$ ls -ln
total 8
-rw-rw-r-- 1 1001 1001 994 Jan 7 20:16 docker-compose.yml
-rw-rw-r-- 1 1001 1001 5 Jan 7 19:46 secret.txt

The owner and permission mask matches the one you saw in the docker-compose deployment.

if change the permission mask or the owner on the host, you will see the change in the container as well.

[gurmit456]

Thank you for detailed response. My problem is solved by setting the correct permission flags on the host.

I was using docker-compose to deploy on the dev machine. I missed the warning but yes they are being produced.