Please expose current user and group ID as new variables for use inside docker-compose.yml

[hartwork]

Is your feature request related to a problem? Please describe. Hi, docker-compose rocks, keep up the good work! :pray: I had cases where the container should be running with the same user and group ID as the docker-compose process, e.g. so that files created inside the container will start out with the right owner without any need for initial root permissions (which is not cool for security) or chown'ing files et cetera.

As of today, inside docker-compose.yml a service definition can already ask for a specific user by means of syntax user: "<user_id>:<group_id>" but there are no predefined variables to effectively achieve something like user: "$(id -u):$(id -g)" from inside the YAML file with convenice. The list of Compose file and CLI variables does not document any variables like that.

Here's a few documented examples for other people trying to achieve the same, and they all need to resort to means outside the docker-compose.yml file: [1] [2] [3] [4] [5] [6].

Describe the solution you'd like It would be great to have two more predefined variables:

• COMPOSE_USER_ID predefined with the effective user ID, as return by $(id -u)
• COMPOSE_GROUP_ID predefined with the effective group ID, as return by $(id -g)

With those two variables, a docker-compose.yml file could now use syntax user: "${COMPOSE_USER_ID?}:${COMPOSE_GROUP_ID?}" to conveniently have a container running as the same user as the one calling docker-compose. Wouldn't that be nice! :smiley:

Feature request #3849 seems to be rooted in a similar need, but my impression was that the door to arbitrary code execution has been kept shut for security reasons so far and adding two variables should work without questioning the current threat model.

Describe alternatives you've considered You could define COMPOSE_USER_ID and COMPOSE_GROUP_ID outside of docker-compose.yml e.g.

COMPOSE_USER_ID="$(id -u)" COMPOSE_GROUP_ID="$(id -g)" docker-compose run ...

but it's not very convenient, does not work out of the box, and it's not standardized.

Additional context

# cat docker-compose.yml 
version: "3"

services:
  debian:
    image: debian:sid
    user: "${COMPOSE_USER_ID?}:${COMPOSE_GROUP_ID?}"

# COMPOSE_USER_ID="$(id -u)" COMPOSE_GROUP_ID="$(id -g)" docker-compose run debian sh -c id  # unpatched
Creating tmpyvecgpc8mx_debian_run ... done
uid=1000 gid=1000 groups=1000

# docker-compose run debian sh -c id  # patched future release, same effect
Creating tmpyvecgpc8mx_debian_run ... done
uid=1000 gid=1000 groups=1000

[hartwork]

Any thoughts?

[prokher]

Honestly, I am waiting for this feature for years already, this is the last thing keeping me from throwing away scriptware around the Docker Compose. I need UID & GID for the same purpose I suppose.

[muxator]

Hi, I think this is a much needed feature. Currently, security-sensitive users need to invert all sorts of alternatives to run containers as a restricted user. Or worse, there may be someone who just does not care and leaves files owned by root laying around in the system.

This proposal seems to be sufficiently simple to be embraced by the sheer majority of the community.

[vmgustavo]

I am currently working on a project where I need exactly this: to run the container with the same user and group as the host to avoid permission problems.

The solution given in the "Additional context" of @hartwork comment is enough, but a more robust solution would be interesting.

[hartwork]

@docker any thoughts?

[MetalArend]

I saw some mentions of a variable called $DC_UID, but it does not seem to work.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hartwork]

Ping, this is still relevant.

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[briceburg]

yes, there is a common need for this and if it were supported natively instead of requiring a wrapper, the better!

[grantwest]

Still a very relevant feature request. If you are using volume mounts with any of your compose containers and the container writes anything to the mount you end up with root owned files.

[shaileshaanand]

yes, there is a common need for this and if it were supported natively instead of requiring a wrapper, the better!

@briceburg What wrapper are you referring to?

[typoworx-de]

May this be possible with some kind of docker-compose plugin?! I've already looked over the dev-docs for them, but obviously there is no plugin-template type that directly matches this purpose.

[tuky]

This would be great to support OOB working dev environments with vscode: https://code.visualstudio.com/docs/devcontainers/create-dev-container#_use-docker-compose. I dream of checking out a repo, pointing vscode to open it and the whole environment spins up and is ready to develop and write code. The only thing that stops this like a road bump is that you as a developer are forced to create a .env file and fill in something like CONTAINER_UID=1000. that's why our compose file actually has this to warn about the missing env file:

user: "${CONTAINER_UID:?please always set CONTAINER_UID when running with docker compose, e.g. put 'CONTAINER_UID=501' in your .env}"