Secrets fail to set the uid, gid and mode specified in docker-compose.yml

[sanchitbapat]

Description

Docker secrets specified using the long syntax for the docker-compose.yml file fail to set the specified uid, gid and mode.

Also, from the docs, the default value of the uid and gid fields should be the user that runs the container however the value remains whatever was set on the host machine.

Steps to reproduce the issue:

1. Create a Dockerfile

❯ cat Dockerfile
FROM ubuntu:20.04

RUN adduser tester -u 1005 --disabled-password
CMD ["/bin/bash", "-c", "ls -al /run/secrets/target_secret_file.txt"]

2. Create a docker-compose.yml

❯ cat docker-compose.yml
services:
  secrets-tester:
    build: .
    secrets:
      - source: some_secret_file
        target: target_secret_file.txt
        uid: "1005"
        gid: "1005"
        mode: 0440

secrets:
  some_secret_file:
    file: somefile.txt

3. Create a text file for secrets (somefile.txt)

❯ cat somefile.txt
Text from a secret file

4. Run the service docker compose run secrets-tester

Describe the results you received:
Received Output:

❯ docker compose run secrets-tester
-rw-r--r-- 1 1000 1000 24 Jul 13 16:47 /run/secrets/target_secret_file.txt

Describe the results you expected:
Expected Output:

❯ docker compose run secrets-tester
-r--r----- 1 1005 1005 24 Jul 13 16:47 /run/secrets/target_secret_file.txt

Additional information you deem important (e.g. issue happens only occasionally):
Same behavior is observed in these cases:

1. Without creating the tester user
2. With same source and target names for the file in docker-compose.yml
3. Using the uid and gid for root
4. Using random values for uid and gid
5. Different values for mode

Output of docker compose version:

❯ docker --version
Docker version 20.10.17, build 100c701

❯ docker compose version
Docker Compose version v2.6.0

Output of docker info:

❯ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
  compose: Docker Compose (Docker Inc., v2.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 1
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.1.2-0-ga916309
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.102.1-microsoft-standard-WSL2
 Operating System: Ubuntu 20.04.4 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.763GiB
 Name: DESKTOP-IGS6AOM
 ID: MBVL:76QX:UWDQ:AK7Z:BNGW:PYGL:EXFG:ZHGD:JM53:RBFZ:4SQV:5I7Z
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support

Additional environment details:

[ev-adias]

Same thing happens to me. I'm trying to use secrets to workaround having to set the permissions on the host file, by setting the mode in the secret, but it end up with the exact same permissions of the host.

This issues comes up for me when using a keyfile for MongoDB replica authentication. The keyfile must not be world-readable, and in *nix this is easy to fix, in Windows (docker-desktop) it's not, so I was hoping that using secrets might fix the problem. It seems not

[markkrj]

As bind mounts do not support different permissions (uid, gid and mode), I suspect that in order to support this, the content of such secrets must be copied into the container (as in #9553), or, use POSIX ACLs (more complex). Am I right @ndeloof?
But why does the compose documentation mention such options if they are not supported in the first place?

[rijnhard]

well secrets and configs arent writeable (as per specification) so no reason why the implementation cant actually be a copy.
unless the idea is that they can change during runtime...

[mario-gravel]

I'm using a secret for a SSH Private Key that must have a 0400 mode. Setting the uid, gid and mode is a requirement.

    secrets:
      - source: ssh_host_ecdsa_key
        target: /etc/ssh/ssh_host_ecdsa_key
        mode: 0400

2022-12-14 20:41:23 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2022-12-14 20:41:23 @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
2022-12-14 20:41:23 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2022-12-14 20:41:23 Permissions 0777 for '/etc/ssh/ssh_host_ed25519_key' are too open.
2022-12-14 20:41:23 It is required that your private key files are NOT accessible by others.
2022-12-14 20:41:23 This private key will be ignored.
2022-12-14 20:41:23 sshd: no hostkeys available -- exiting.

[ndeloof]

Same issue applies both to Compose v1 and v2
the root cause is that both use a bind mount to "inject" secret inside container, but bind mount doesn't allow a distinct UID/GID/mode to be exposed inside container.

A possible alternative I can imagine is to replace this approach with a copy (just like we do with support for secret set by environment). The sole drawback is that, doing so, changes to secret on host won't apply to secret inside container. Doesn't seem to be a major issue to me, but let me know if this would be a blocker for your usage.

[mario-gravel]

In my own opinion, having to rebuild the image to change a secret isn't an option. Major issue? Not now because we haven't reach the production, we're still developing. But once in production, it will be a security concern.

The access to the container repository isn't as secure as the access to the production host. Somebody pulling the image will have access to the private keys. Not a good thing at all !

There must be control over the uid, gid and mode for a secret file.

[ndeloof]

having to rebuild the image to change a secret isn't an option

This is not my proposal: compose would copy the secret into the container (not image) after creation, and before start. This is how secret based on environment is implemented already.

[mario-gravel]

Oh, my bad ! Sorry 'bout that !

[mario-gravel]

So if a secret change, we need to restart the container. Am I right ?

[ndeloof]

yes indeed

[mario-gravel]

Does it implies a redeploy of the container or just the starting phase will be enough ?

It would be great if a refresh can be triggered manually (ex: docker compose refresh-secrets) to redo the copy in the container. Having a watchdog to do this automatically may consume resources unnecessary. Secrets don't change often but being able to update them without a restart can be a good solution.

[ndeloof]

we could copy secret again at any time, or have a dedicated command for this purpose, but the more obvious one would be to trigger a container restart

[mario-gravel]

As long as the secret file can be updated on the fly and still have the good uid, gid and mode, I'm good !

[rijnhard]

I agree with the suggestion on a copy implementation, my use case is local development since I want to align local dev with a production swarm and a quick restart on local is totally acceptable to me.

…

On Thu, Dec 15, 2022, 16:14 Mario Gravel ***@***.***> wrote: As long as the secret file can be updated on the fly and still have the good uid, gid and mode, I'm good ! — Reply to this email directly, view it on GitHub <#9648 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAXP2FJAB2TJB5D2UDM2BDWNMRVRANCNFSM53PZWJBQ> . You are receiving this because you commented.Message ID: ***@***.***>

[cu]

I was testing out the secrets functionality using docker compose version 2.14.1 today and was surprised to learn that they don't work the way the docs say they should.

$ cat docker-compose.yaml 
services:
  bb:
    image: busybox
    command: sleep infinity
    secrets:
     - source: my_secret
       target: /secret_file_target
       uid: "1234"
       gid: "5678"
       mode: 0400

secrets:
  my_secret:
    file: ./secret_file_source

$ echo "this is my secret file" > secret_file_source

$ docker compose up -d
$ docker compose exec bb ls -l secret_file_target
-rw-rw-r--    1 1000     1000            23 Jan 11 22:38 secret_file_target

This also seems to affect configs as well.

[ndeloof]

Marking this issue as "kind/enhancement" as secrets never have supported having uid/gid set by compose (v1 or v2), this feature was introduced and only supported by docker swarm

[peterge1998]

I'm using a secret for a SSH Private Key that must have a 0400 mode. Setting the uid, gid and mode is a requirement.

    secrets:
      - source: ssh_host_ecdsa_key
        target: /etc/ssh/ssh_host_ecdsa_key
        mode: 0400

2022-12-14 20:41:23 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2022-12-14 20:41:23 @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
2022-12-14 20:41:23 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2022-12-14 20:41:23 Permissions 0777 for '/etc/ssh/ssh_host_ed25519_key' are too open.
2022-12-14 20:41:23 It is required that your private key files are NOT accessible by others.
2022-12-14 20:41:23 This private key will be ignored.
2022-12-14 20:41:23 sshd: no hostkeys available -- exiting.

Can confirm this failing behavior (setting mode, uid & gid) which is not working for me too.

$ docker --version
Docker version 20.10.23, build 7155243
$ docker compose version
Docker Compose version v2.15.1

I came across this when I wanted to mount a private ssh key to the checkmk/check-mk-raw container via docker compose secrets and specify uid, gid & mode for the key, when I got the same UNPOTECTED KEY warning when executing ssh manually.
According to the docs, this should be possible but did not work for me too.

[noahehall]

@peterge1998 the key thing about the docs is the explicit wording

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 running container.

a service task explictly refers to swarm containers

[AnderssonPeter]

It would be nice if this was supported when using docker compose I run the a container where the process runs as nobody.
So o give it access to the secret I have to give nobody read access to it on the host.

So if anyone gains access they can read the secrets in question without gaining root access.

[zorgoz]

Is there any roadmap for this feature (I needed this with configs, not secrets)?
Just wondering: why is it not in the docs, that this is actually not supported?

[andrewvaughan]

@ndeloof

latest docker compose release warn you about this feature not being supported

WARN[0000] secrets `uid`, `gid` and `mode` are not supported, they will be ignored 

the reason is that secrets are implemented as bind mounts, which comes with this limlitation.

This error actually was more confusing than helpful to me, and is what led me to finding this discussion. It is seemingly counter to the Compose documentation, which makes it seem like they are supported.

Only reading through this entire discucssion did I learn that the Docker team uses the term service as both a swarm-only term and as a top-level mapping in the Compose documentation. There's no way users are just going to "know" that this is the case, and, at minimum, warrants an asterisk on the documentation explaining so. Requiring your users to understand how Swarm works should not be a dependency for being successful with Compose.

I'll add my $0.02 that this seems to be a severe limitation to Docker Compose Secrets and implementation should be reconsidered. This leaves the use of secrets at the whim of the image maintainer as to whether they build in a fashion that allows for access or not.

For example, in the formal Postgres docker container, they run all entrypoints as a 999:999 (postgres) user, meaning secrets become inaccessible during entrypoint and beyond. This severely limits the ability to extend that image's functionality with any use of secrets or add any dynamic capabilities through a Docker Compose configuration.

[spectrapulse]

I’m frustrated with the inadequate documentation and inconsistent support between Docker Swarm and Compose. This is the seventh instance I’ve encountered where Swarm lacks support for a feature that Compose offers, or vice versa.

It feels misleading to promote the capability of managing both environments with a single unified configuration in the documentation when, in reality, the latest version of Docker CE does not support the new Compose specification in Swarm. Unfortunately, Swarm lacks dedicated documentation that clearly delineates supported and unsupported features. This time, I’m struggling to mount secrets or configurations in a Compose environment because the application in the container expects specific file permissions, which necessitates a workaround. This issue likely stems from the decision to share a specification across two distinct tools with different levels of support for this spec, both of which are provided by the same vendor.

If the intention is for this to be a standalone specification, it should be renamed from “Compose File” to a more tool-agnostic term. The documentation should explicitly state when a feature is not supported by these tools—before developers encounter errors during the transition from development to a small production environment, not after, and certainly not through a GitHub Issue due to an unhelpful error message.

I can foresee further confusion with the introduction of Compose Bridge, particularly if it lacks comprehensive documentation. This oversight leads to significant time wasted especially when designing around functionality provided by these tools.

[ndeloof]

It feels misleading to promote the capability of managing both environments with a single unified configuration

docker swarm does not rely on the compose specification, but on legacy compose file format. So there's no promise here you get a unified configuration.

If the intention is for this to be a standalone specification, it should be renamed from “Compose File” to a more tool-agnostic term.

"Compose specification" https://compose-spec.io/

further confusion with the introduction of Compose Bridge, particularly if it lacks comprehensive documentation

please be patient, Compose bridge is still fresh new experimental feature, more docs will come ASAP

[polarathene]

latest docker compose release warn you about this feature not being supported

WARN[0000] secrets `uid`, `gid` and `mode` are not supported, they will be ignored 

the reason is that secrets are implemented as bind mounts, which comes with this limitation.

Just as additional awareness for others in this issue, you'll still get this warning for environment and content type sources for secrets / configs when you attempt to use those additional settings, but despite the warning they are valid and applied for environment / content sources, not ignored.

It probably would be beneficial to readers though if the docs at least clarified the common distinction of the types that aren't compatible/supported with Docker Compose considering the repo and docs hosted at Docker the majority of readers landing there are probably Docker Compose users?

The warning at least lets the reader know about the compatibility issue after they've parsed over the docs and attempted it... not the greatest UX but still something. It just shouldn't be adding to confusion though when the feature itself is supported by the configured source type (or in the case of some config/secret sources being compatible in the compose.yaml while others are not, the warning could better clarify the incompatible source types if the official docs won't).

[wz2b]

This capability is something you need even if you aren't using swarm.

[owl-with-beard]

I stumbled upon this issue exactly as @ev-adias did almost 2.5 years ago, wondering why my MongoDB key files were not working. I'm sorry, but this is clearly a flaw in the documentation. It's sad that this feature seems not to be on any road map to be brought to docker compose, but so be it. It is however almost rude and a gigantic waste of my time and the time of many other devs out there to not put anything in the documentation that states that this feature is only implemented in Docker Swarm and not supported in Compose.

Adjusting the documentation takes minutes and saves many people many hours. I don't understand why this was not done yet.

Best regards

[ndeloof]

It's sad that this feature seems not to be on any road map to be brought to docker compose

@owl-with-beard uid, gid and mode have been introduced bby docker swarm, and have no obvious equivalent in compose that would allow to add support on a non-swarm docker engine. The question is not about priorization in our roadmap, but feasability.

this is clearly a flaw in the documentation

indeed. The sad point here is that the compose specification (compose-spec.io) is supposed to be vendor neutral, so we can't bring much details on actual support by Docker Compose. I wonder we could relax this rule, as there's actually not much third-party contributions.

[quarky42]

This page is not updated to explain the limitation:
https://docs.docker.com/reference/compose-file/services/#secrets

It needs to be.

This next page was updated finally. I have submitted feedback on docker pages asking that this be made clear because of the ridiculous amount of time I've spent on this issue previously.
https://docs.docker.com/engine/swarm/secrets/#windows-support

I patently reject your defeatist attitude regarding support for a fundamental user, group, and mode control of files in compose services on Windows. A 30 second search turns up an option for supporting uid, gid, and mode used WSL Meta data on Windows:
https://learn.microsoft.com/en-us/windows/wsl/file-permissions

Docker runs on WSL by default. If this feature was supported when WSL was available that would be of great benefit to many.

If for some reason that was prohibitive, I'm certain another solution could be found such as creating a ramdisk for secrets using tmpfs or other format, copying the secrets there at service startup, and applying the permissions.

There are two ways to solve this off the top of my head. Does a solution have to be perfect to at least be better than zero support? A solution with minor limitations is better than no solution at all when it comes to a hard requirement to support file permissions and ownership. Multiple docker services require their config files to configured with permissions in order to boot. The workarounds to avoid making this work in Docker Compose not only waste our time, they make divergent compose settings. Being able to develop with docker compose and deploy with swarm seems to be the promise that Docker is falling short on.

[polarathene]

It's sad that this feature seems not to be on any road map to be brought to docker compose, but so be it.

#12448 (comment)

This would resolve the lack of support apparently. It's unclear if that'll get merged though given the review feedback so far.

---

I wonder we could relax this rule, as there's actually not much third-party contributions.

I think many that view the Compose reference docs at docs.docker.com are doing so with Docker Compose in mind.

You can always add an admonition or similar UI element to add some context for clarity. These types of caveats do harm the UX and cause confusion to users trying to leverage them when there's a lack of clarity and they need to troubleshoot and potentially find some resources elsewhere online clarifying the situation.

Another example I ran into recently was opt-out for a service from docker compose up, depending where you look there's scale: 0 or profiles: ["no-up"] (or similar).

[ndeloof]

This page is not updated to explain the limitation

should be, indeed.

I patently reject your defeatist attitude

This is not defeatism, I've tried various approches to this issue in the past, without much success (most recently #12625). I'm not saying we will never offer this feature, just we don't have the adequate features exposed by the engine API to succeed yet.

A 30 second search turns up an option for supporting uid, gid, and mode used WSL Meta data on Windows

Which demonstrates you're under-estimating the actual challenge we have to address here. The question is not to get this running from WSL within Docker Desktop, but to get this supported in the Docker engine API, which hardly will accept such a non-portable option that can't be supported on Linux.

A solution with minor limitations is better than no solution

Considering Docker engine without swarm enabled has no support for configs and secrets, the existing behavior already is a solution with known limitations. The other option is for you to include configs/secrets in your image as a build step, maybe relying on dockerfile_inline inside your compose file if you rely on an existing image.

@polarathene #12448 coms with some limitations and breaking changes (which I tried to address in #12625). Those are significant enough so that we don't want to silently switch from bind mount to such a solution without an explicit opt-in by compose file author, otherwise we will have to deal with regression reports (many users rely on the bind mount behavior to get config/secret dynamically updated in container)

[ndeloof]

Just a quick note:

With lack of native support for secrets/configs in docker engine (non-swarm) a possible workaround is to build a specific image for compose to COPY required files inside container:

services:
  app:
    secrets:
       - source: app_config
          target: /etc/
          uid: <UID>  # not supported
          gid: <GID>

secrets:
   app_config:
      file: ./app.cfg

can be replaced by:

services:
  app:
    build:
      dockerfile_inline: |
        FROM myapp
        COPY --chown <UID>:<GID> ./app.cfg:/etc/

This is far from being perfect, but at least wanted to get this documented in this issue for those blocked by this limitation

[polarathene]

@ndeloof no worries! I appreciate all the time and effort put into figuring out a solution 😎

Slightly-offtopic, but is there any blockers for ID mapped support?

• I think that may be limited to rootful containers, and may be dependent upon Docker Engine moving to containerd 2.0 (I thought that was the case with v28 due to some PRs bumping containerd deps to 2.0, but it still seems to ship with 1.7.x).
• It'd allow for bind mounts with UID/GID mapping AFAIK, not sure about mode changes though.

I did try to get it working with compose and volume mount options a while back but ran into some issue that presumably is a limitation with Docker Engine, it worked fine to create the equivalent mount on the host without docker involved though.

[schaubl]

Hi all,
Happy to see discussions ongoing on this topic.

---

#12448 (comment)
This would resolve the lack of support apparently.

@polarathene: Yes it does resolve it for file based configs and secrets.
The ones based on environment and content already support setting the uid, gid and mode.
My PR resolve it by using the same implementation as for environment and content (copying the file in the container).
It doesn't support directories, only a single file (as for environment, content and swarm/stack).

---

I don't have a very strong opinion on that but I don't think directories should be supported because I think it doesn't match the original concept behind configs and secrets and it also have some implementation issues like using mode with sub-directories (should they have the same permissions as the files ?) and there are probably a lot of cases where not all the files should have the same permissions. Also the doc always mentions "file" and not "files"/"directories" (starting with the param name itself).
However I do agree that in some cases being able to inject files and directories could be useful.
Maybe the solution for this point would be to have an extra parameter named like path/files/directories which would be specific to Docker Compose (on top of file which will keep similar behaviour as in swarm/stack).

---

@polarathene #12448 coms with some limitations and breaking changes (which I tried to address in #12625). Those are significant enough so that we don't want to silently switch from bind mount to such a solution without an explicit opt-in by compose file author, otherwise we will have to deal with regression reports (many users rely on the bind mount behavior to get config/secret dynamically updated in container)

@ndeloof: Would it be enough to add a big warning of the behaviour change (and the way to update compose files) in the release notes as you initially mentioned here #11867 (comment) ?
I don't know how many users rely on the bind mount behaviour but I find strange to use configs/secrets for this when bind mounts are already available. The only use case I can see is if a user uses a secret to share sensitive informations to the container but this is even worse because the user think there are extra security measures which is not the case.
In case what the user wants is a bind mount, there is a drop-in replacement (bind mounts) but unfortunately if we have to inject a file into a container when docker compose is executed from a remote machine, there is no alternative.

[polarathene]

I don't know how many users rely on the bind mount behaviour but I find strange to use configs/secrets for this when bind mounts are already available.
The only use case I can see is if a user uses a secret to share sensitive informations to the container but this is even worse because the user think there are extra security measures which is not the case.

That happened for me when I initially came across it and thought from the docs (at least back then, haven't checked the current docs for it) that it was meant to be more secure, along with the uid/gid/mode features to ensure it is when providing a file.

It's only because I noticed in the container none of those settings actually applied outside of swarm that I realized it was effectively a misleading bind mount with different syntax added as a fallback convenience for swarm users (actual justification for it IIRC).

---

As for avoiding regression reports from existing users... I suppose until you're ready to make it a breaking change, one option is to go opt-in as suggested with something like secure: true as the opt-in attribute.

Then clearly document that the secrets feature on non-swarm is not secure by default for legacy reasons, and requires additional explicit opt-in to toggle on the secure feature, with the caveat you lose the ability to sync updates from the host? 🤷‍♂

Technically since uid/gid/mode aren't supported in the existing support and this is specific to behaviour on non-swarm usage...there's no reason those users should be configuring those given they don't do anything thus you might as well make any of those the opt-in trigger instead, nothing new to add then. Documentation just needs to be clear that those options will break the current functionality of being treated as a typical bind mount? 🤔 (EDIT: Oh I just realized that the referenced PR is doing exactly that for opt-in via uid/gid/mode usage)

[ndeloof]

I don't think directories should be supported because I think it doesn't match the original concept behind configs and secret

A common pattern is to declare a whole config.d folder as a compose config and use it inside container. Many tools support this modularity pattern so that user don't hav to maintain a huge config file but can provide fragments

I don't know how many users rely on the bind mount behaviour but I find strange to use configs/secrets for this when bind mounts are already available

This was introduced to offer some parity with docker swarm, then users started relying on it in development to get immediate update on config changes (which could be implemented with watch nowadays). Then, with thousands example and stackoverflow suggestions you'll see tons of users to select this option without any specific reason. Still we have to manage our legacy to prevent compatibility breaks.

[schaubl]

@ndeloof thanks for your answers.

---

To manage the legacy, I think it could be possible to create an environment variable like USE_OLD_CONFIGS_SECRETS which will default to True/1 (similarly to the COMPOSE_BAKE introduced recently in v2.33.0).
At the same time, a warning can be added in the release notes to mention that the default value of this variable will, in the future, be changed to False/0.
With this, the current implementation will still be applied by default (for now) while allowing users to use the new implementation (by setting USE_OLD_CONFIGS_SECRETS to False) and for users relying on the current behaviour, they will have time to either migrate to bind mounts or to set USE_OLD_CONFIGS_SECRETS to True.
@ndeloof What do you think about this strategy ?

---

Regarding the PR #12625, if I understood properly, bind mounts will still be used for file except if one of the uid, gid or mode params are set.
I have the impression that this could adds more confusion because the behaviour on handling the file will be completely different based on the usage or not of at least one of the 3 parameters mentioned above.
This is especially true when the docker compose command is executed from a remote machine. In this case, for example, if I want to inject my /etc/hosts file into the container, it will work if I explicitly set its mode but if I don't, it will take the /etc/hosts of the machine where the docker daemon is.
Also the behaviour can be different inside the same compose file, because the file param is in the top-level configs but mode is in the service-level configs so if I have a config used by two services where I need to change the permissions for only one service, the two different behaviour will be used and with my example with the /etc/hosts file, I will end up with two different file contents in the two containers even that they both use the same config.

services:
  A:
    image: alpine
    configs:
      - source: etc_hosts
        target: /etc/hosts
    command: cat /etc/hosts
  B:
    image: alpine
    configs:
      - source: etc_hosts
        target: /etc/hosts
        mode: "0777"
    command: cat /etc/hosts
configs:
  etc_hosts:
    file: /etc/hosts

[ndeloof]

@schaubl fully agree. #12625 is just an experiment to prevent breaking changes, still unpleasant - also comes with multiple drawbacks I can't detail here. As you noticed, secrets support in compose was designed with local engine in mind (or Docker Desktop) but won't support an actual remote engine. On the other hand, if we use copy to inject files inside container, we then miss a mechanism to enforce consistency when local config/secret is updated.

it will take the /etc/hosts of the machine where the docker daemon is

Please note this is exactly what some expect !

The best option I have in mind is for docker engine to enable secrets/config support in standalone (non-swarm) mode. I can't tell about how complex this could be, but for sure the code is already there :P cc @colinhemmings
@thaJeztah I haven't found an open issue requesting such a feature on moby repo, does this ring a bell ?