I need to make my host user's `~/.git-credentials` available inside a container so a program can use Git authentication. The file is owned by my host user and has mode 600. It must not be included in the image, and I cannot change its host permissions or bake host UID/GID information into the image. The payload must run as a separate non-root user inside the container, not as root. I also want a solution using Docker or Compose directly, without writing a host-side wrapper script, creating another service or vault, or otherwise working around these constraints. A read-only bind mount and file-based Compose secrets currently expose the original host ownership, so the container user cannot read the file. What viable options are there?
4 Answers
The usual container pattern is to start an entrypoint as root, read or copy the mounted secret into a protected location, set ownership for the application UID, and then drop privileges with something like `gosu` or `su-exec`. That does not satisfy the requirement that the container never start with root access, but it is a common practical solution. Docker Swarm or Kubernetes secrets can provide stronger runtime secret handling, though introducing that infrastructure just for a local CLI workflow may not be worthwhile.
With all of those constraints, there is no general way to make a mode-600 file readable by a different UID without changing how the file is presented or using an intermediary. A bind mount preserves the host file's ownership and permissions. Docker Compose's `uid`, `gid`, and `mode` settings do not remap permissions for file-backed secrets; they are effectively ignored when Compose implements the secret with a bind mount. You would need to relax at least one requirement: run the container with the matching UID, use an environment-based secret, copy or transform the secret during startup, or use a secret manager/orchestrator that materializes it with the desired ownership.
The underlying limitation is fundamental: access requires some combination of matching identity, readable permissions, a privileged process that can copy or change ownership, or a service that mediates access. Docker cannot make an arbitrary host file readable by a different non-root UID while simultaneously preserving the host permissions and avoiding all intermediary handling. If none of those alternatives is acceptable, the requirements are mutually incompatible.
Be careful about giving a coding agent your personal Git credentials. Create a separate credential with the minimum required repository permissions, and preferably make it short-lived or otherwise revocable. Passing the value through an environment variable can work for a manual launch, but secrets may remain visible through process or container inspection and can be accidentally logged. A single-user container whose internal UID matches the host file owner is simpler, provided the container is sufficiently trusted and the mounted file is read-only.
The Compose example claiming that `uid: 1000`, `gid: 1000`, and `mode: 0600` fix a file-backed secret is misleading. The Compose documentation says those attributes are only implemented for environment-backed secrets; file-backed secrets use a bind mount and cannot be remapped this way.