moby: Incorrect mode for docker-compose secret file
According to the docs, the permissions for secrets files:
The default in Docker 1.13.1 is 0000, but is be 0444 in newer versions
And according to a previous issue, this was fixed.
But this is not the case for me.
- I have a secret file on the host with permissions
400
. It is referenced indocker-compose.yml
for a mariadb service. But mariadb errors with “permission denied”. - If I change the host secret file to
444
, then it works, but of course that’s a bad idea.
I thought 444
(for the container secret file: /run/secrets/foo
) was supposed to be the default mode set by docker?
ubuntu 19.04
docker --version
= Docker version 19.03.2, build 6a30dfc
docker-compose --version
= docker-compose version 1.24.1, build 4667896
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 9
- Comments: 17 (6 by maintainers)
Docker Compose doesn’t support real (swarmkit) secrets, and imitates them by bind-mounting the file directly into the container (which means that permissions on the host are the same as in the container).
You can change the ownership of the file on the host to match the uid/gid of the user in the container, but otherwise I don’t think there’s much that can be done unfortunately
I’ll close this issue because of the above, but feel free to continue the conversation
I think ideally the file would not be stored at all (as plain text), and used in a configuration management system or a password manager, then the secret created in advance.
Docker doesn’t need access to the file once it’s been stored as a secret (
docker secret create
)If you do need the file locally, you can store it with
0400
permissions somewhere in your own home directory, so that only you (the person runningdocker stack deploy
) has access to it.@raratiru @niloct @JustinGuese @wbadart @MohammedNoureldin @Soberia @michitaro I see you upvoted this issue. If this is still important to you, please upvote this new feature request, and/or add your opinions there.
@thaJeztah, any chance for contribution in order to somehow fix this issue and make it also work in docker-compose?
This ticket was about
docker-compose
, which does not use swarm services.If you’re using swarm services, you can set the
uid
,gid
and permissions when attaching a secret to service.Looking at the elasticsearch Dockerfile (https://github.com/elastic/dockerfiles/blob/v7.10.1/elasticsearch/Dockerfile#L70-L73), the
elasticsearch
user hasuid:gid
1000: 1000
, so if you would mount the secret withuid=0
(root) andgid=1000
(elasticsearch group), then permissions0440
, it should have access.Create a secret
Create a service using the secret, that mounts it at
/run/secrets/foo
, with owner0:1000
, and0440
permissions;exec into a container of the service as user 1000:1000, verify ownership/permissions are correct, and that user
1000
is able to read the secret;Hi, thanks for replying 😃
Considering that in this scenario the container doesn’t run under root, and the user hasn’t sudo privileges, even if he compromises the container he wouldn’t be able to see the secret.
Right ?