Devcontainer does not update remote user's UID to match host machine's UID when group already exists

[KyleRAnderson]

• VSCode Version: 1.67.2 (user setup)
• Local OS Version: Windows_NT x64 10.0.22000, but running over Remote - SSH on an Ubuntu 20.04 host.
• Local chip architecture: x86
• Reproduces in: Remote - Containers
• Name of Dev Container Definition with Issue: Update UID feature applied to any devcontainer. In this case, I was using the C++ devcontainer.

Steps to Reproduce:

1. On the container host, create a user with a UID of something other than the default 1000 (I used 1577 in my case) and a GID of 100.
2. Create a C++ VSCode devcontainer definition with no modifications and launch the container. I tried this using the ubuntu-20.04 , ubuntu-21.04 and debian-11 variants, it doesn't seem to matter.
3. Check whether the remote user's UID has been updated to 1577. In my case, it had not been updated, causing permission issues when writing files in the bind mount from the host system.

I did a little bit of investigation into why this is the case by looking at the Dockerfile that the UID update feature uses. It looks like what is happening is that a group with ID 100 already exists in the container so the feature skips updating both the UID and GID. However, I do not understand why this logic is in place as we would still want to update the UID in this case, and I see no harm as well in assigning the vscode user to the existing GID.

[joshspicer]

Perhaps @Chuxel can weigh in on this design decision.

Just want to make sure - is this purely based on curiosity, or is the current logic we have here causing a problem of some kind that can't be solved by manually setting the UID and GID? Am I correct that the default UID/GIDs (of 1000, I believe), would work?

[Chuxel]

This sounds like a dupe of microsoft/vscode-remote-release#2402. This is not about the images in this repo, but rather what is possible when doing UID/GID syncing.

The core challenge is that it's a bit unclear as to what is safe to do in this scenario - low group IDs like that are often system groups, so reusing likely isn't safe to do. I'd suggest moving the conversation to this existing issue. However, 100 is "users" so in concept that could be made an exception.

Closing as a dupe, more discussion can happen over in the other issue.