search

microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.67k stars 293 forks source link

updateRemoteUserUID has no effect #10030

Closed PhilDay-CT closed 2 months ago

PhilDay-CT commented 4 months ago

I'm running a dev container created from a base Ubuntu 24:04 image with and additional user account

$ cat Dockerfile 
FROM ubuntu:24.04
ARG USERNAME=guest
RUN useradd -m $USERNAME 
USER $USERNAME
CMD bash

$ docker buildx build --file Dockerfile  -t usertest:1.0.0 --load .
...
 => sending tarball                                                                                                                                                                             0.2s
 => importing to docker                                                                                                                                                                            0.0s

$ docker run -it usertest:1.0.0 bash
guest@c430c4b72d70:/$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)
guest@c430c4b72d70:/$ 
exit

On my host system my user id is 1000

$ id
uid=1000(phil) gid=1000(phil) groups=1000(phil),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare),999(docker)

Using this with the following devcontainer.json I was expecting the updateRemoteUserUID option to update the UID/GID to match my local UID/GID - which as per (https://containers.dev/implementors/json_reference/) I need to avoid permission issues in the mount, but it doesn't happen. 

{
  "image": "usertest:1.0.0",
  "remoteUser": "guest",
  "containerUser": "guest",
  "updateRemoteUserUID": true
}

When I open a terminal in VSCode in the Docker the id is still set to guest

$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)

$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy


- Remote OS Version:
ubuntu:24.04

$ uname -a Linux 7558979553bb 6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux


- Remote Extension/Connection Type: Containers/WSL/Server
Containers

Steps to Reproduce:

See above for a simple Docker build that shows the issue.  You need to ensue that the host uid and uid in the docker image don't match. 

<!-- Check to see if the problem is general, with a specific extension, or only happens when remote -->
Generally - when using any docker image where the uid in the image does not match the uid in the container.
davidchisnall commented 4 months ago

We started seeing this issue after upgrading our dev container base from Ubuntu 22.04 to 24.04. The 22.04 base image has no existing users and so creating a non-root user gives a UID of 1000, with 24.04 there's an ubuntu user with UID 1000 so our UID is 1001. This has probably been broken for a while but was hidden by the fact that all of the people using our dev container on Linux use the first interactive user ID, which happened to match the user in the container.

We can work around it somewhat by forcing the UID of the user in the container to 1000, but that is just masking the problem.

cadojo commented 3 months ago

I have run into this issue on Ubuntu and MacOS hosts. I think this will particularly affect MacOS users, because MacOS assigns users to the staff group which is a different ID than the user ID, and the user ID is not 1000 or 1001 by default, as it is in Ubuntu. It seems that updateRemoteUserId has no effect.

GuillaumeQuenneville commented 2 months ago

I encountered the same issue, my host uid/gid was 1000/1001. I added 

FROM mcr.microsoft.com/devcontainers/cpp:1-ubuntu-24.04

# Workaround for remoteuser id issue
# https://github.com/microsoft/vscode-remote-release/issues/10030
RUN usermod -u 2000 ubuntu && groupmod -g 2000 ubuntu
...

to the top of the devcontainer Dockerfile as a temporary workaround.

chrmarti commented 2 months ago

We don't update the UID when there already is a user with that UID. In this case Ubuntu 24.04 already has a user with UID 1000, so the UID 1001 user can't be updated to use UID 1000.

@samruddhikhandale This might be tricky to work around in the CLI because it might encounter various base images. Maybe we can work around it in our base images either by removing the ubuntu user or by updating its UID and GID to one that is unlikely to cause a conflict.

GuillaumeQuenneville commented 2 months ago

There are instructions in the advanced section for creating non-root users. https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user. It has a section on editting the UID/GID when creating an image https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user#_change-the-uidgid-of-an-existing-container-user but not if the base-image includes conflicting accounts. At the moment, suggestions that pop up when you search

dev containers eaccess permission
or
dev containers uid and gid don't match

in a search engine don't direct to this documentation and the results that do aren't very useful (other than this issue popping up). Maybe the documentation can be updated to mention these terms for SEO.

samruddhikhandale commented 2 months ago

@samruddhikhandale This might be tricky to work around in the CLI because it might encounter various base images. Maybe we can work around it in our base images either by removing the ubuntu user or by updating its UID and GID to one that is unlikely to cause a conflict.

When noble was released, we had a long discussion regarding how to handle it and we ended up with a collective decision of letting the vscode user be 1001 for noble distro and letting focal and jammy have vscode:1000

Sharing the couple of reasons we thought this was the right way -

@chrmarti It's been three months since we released base images with ^, not sure what's the best way is to handle it. We can still make changes given the fact that noble is not yet latest for the base image. Also, we have seen https://github.com/devcontainers/images/issues/1056

Let me know what you think!

chrmarti commented 2 months ago

Given that this breaks our fix for the workspace file ownership mismatch on Linux (the UID updater) for local UID 1000, I suggest we reconsider our options. We decided to keep the ubuntu user unchanged under the assumption that this would avoid interfering with the base image's setup. I think we probably just delete this user as suggested in https://github.com/devcontainers/images/issues/1056 and then create the vscode user as before (UID 1000 will be reused in this case).

Some background on the ubuntu user: https://bugs.launchpad.net/cloud-images/+bug/2005129

samruddhikhandale commented 2 months ago

We decided to keep the ubuntu user unchanged under the assumption that this would avoid interfering with the base image's setup.

Yes, that was definitely our thoughts there.

I think we probably just delete this user as suggested in https://github.com/devcontainers/images/issues/1056 and then create the vscode user as before (UID 1000 will be reused in this case).

Makes sense, thanks!

chrmarti commented 2 months ago

Continuing in https://github.com/devcontainers/images/issues/1056. Thanks.