Files created inside container are owned by root:root instead of my user

[cleac]

All the files and folders created while opened VSCode inside a container belong to root:root user.

I am not sure if it is issue of extension itself, but definitely makes the development harder.

• VSCode Version: 1.34.0-insider
• Local OS Version: Elementary OS Juno (Linux racoo 4.15.0-48-generic Can't connect to Ubuntu: unreachable or not Linux x86_64 - IO is still pending on closed socket #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux)
• Remote OS Version: ubuntu buinic
• Remote Extension/Connection Type: Docker

Steps to Reproduce:

1. Open a folder inside a container
2. Create some new file.

Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

[chrmarti]

Docker creates the files on the host side with the same owner/group id as inside the container. You could build the container to run with a different user that has the same numeric id as your local user.

This needs more investigation to understand if we can do something in general.

[cleac]

Yeah, this is pretty obvious. However, I hope it is possible to do chown user:user /path/to/file, especially if it runs a root inside a container 😄️

[chrmarti]

Appending the following to the Docker with UID and GUID replaced with the actual ones on the host side seems to work:

RUN addgroup --gid 1000 devuser
RUN adduser --disabled-password --gecos "" --uid 1000 --gid 1000 devuser
ENV HOME /home/devuser

USER devuser

Not sure if we have good hook to change a new file's owner after creating it. @bpasero ?

[bpasero]

@chrmarti you create the file through the IFileService and ask for a way to change the owner? This is not exposed by our file system provider API for extensions as far as I know.

[chrmarti]

@bpasero It would help if we could tell the remote extension host which UID/GID to use when creating new files. Not sure if that would be the best solution.

The other approach would be to automatically create a user with the host user's UID/GID and run the remote extension host with that user. This might sometimes be unexpected, e.g., when root's home directory has customizations not in the default profile for new users.

[bpasero]

@chrmarti this seems like a very specific thing for the remote server, maybe a config option would be better that can be set in the server on startup?

I see no other real use case that would warrant new API for file system provider.

[chrmarti]

I agree, could be a command line argument. /cc @alexandrudima

[MostHated]

I recommend looking into this, it can help solve the uid issues by passing your id/group into the container for it to use. It is typically used for docker containers, but perhaps it can somehow be used in this particular situation?

https://github.com/boxboat/fixuid

[Chuxel]

@chrmarti At this point, there are a number of features coming in that are trying to resolve this issue. These include #46 and #1050 both of which are trying to get at the idea you can pass in the appropriate UID/GID into the container and create a user (by default it requires hand editing).

I looked at making changes to the default templates in vscode-dev-containers, but repeatedly hit roadblocks in automation tricks as described in microsoft/vscode-dev-containers#108

Another I didn't mention, is that you can't use the postCreateCommand to generate the user. This is because you need to specify "-u" in runArgs in devcontainer.json, but the user won't exist yet - which results in an access denied error when trying to set up VS Code server.

fixuid is a partial solution assuming a user exists in the container, but requires that a non-root user exist. Updating the default dev container templates will help, but not solve, that part of the problem. A better solution may be to simply generate a vscode user / group in the container that matches your local uid/gid when the container is initially built and run. We could then have a flag to disable that behavior if preferable.

//cc: @kieferrm since I mentioned this to him today.

[Chuxel]

We left this open since we have not implemented the dynamic UID/GID updating for Docker Compose yet. However, given support is already in for image and Dockerfile scenarios, I'm closing this in favor of a new, more specific issue: #2228.