Update UID/GID with conflicting user/group

[nmoadev]

Issue

The "remoteUser" / "updateRemoteUserID" features of VS Code Remote don't seem to be working when I download this example and try to use it. Steps:

1. Clone this repository to your local filesystem.
2. Press F1 and select the Remote-Containers: Open Folder in Container... command.
3. Select the cloned copy of this folder, wait for the container to start, and try things out!
4. Try to edit server.js and save.
5. See:

Failed to save 'server.js': Unable to write file 'vscode-remote://dev-container+2f6c6f63616c2d7373642f6769746875622f7673636f64652d72656d6f74652d7472792d6e6f6465/workspaces/vscode-remote-try-node/server.js' (NoPermissions (FileSystemError): Error: EACCES: permission denied, open '/workspaces/vscode-remote-try-node/server.js')

6. Check uid via terminal:

node@e14a9f760e96:/workspaces/vscode-remote-try-node$ id 
uid=1000(node) gid=1000(node) groups=1000(node)

System Info

About VS Code:

Version: 1.42.1
Commit: c47d83b293181d9be64f27ff093689e8e7aed054
Date: 2020-02-11T14:50:36.977Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.9.0-8-amd64

Linux Info

$ uname -a
Linux akuchta-deb9-64 4.9.0-8-amd64 microsoft/vscode-remote-try-node#1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux

Extension Info
Remote - Containers: 0.101.1

[Chuxel]

@chrmarti This was originally opened agains the vscode-remote-try-node repo. Combined with #2401, I wonder if something regressed here.

[chrmarti]

This is missing for repository containers. (It works when opening a local folder in a container.)

[chrmarti]

Rereading, that's what doesn't work for you. What's your UID and GID locally? We check if they exists in the container on an existing user or group and don't do the update if they do.

[nmoadev]

UID=12070 and GID=101

When I did quick check of /etc/passwd inside the container I didn't see any entries with matching UID

[nmoadev]

But, it looks like the ssh group inside the container is a conflict:

node@7fa2a522c770:/workspaces/vscode-remote-try-node$ grep 101 /etc/group      
ssh:x:101:

Is there a way to workaround this easily?

[chrmarti]

Making the user part of an existing group seems like a bad idea. One option might be to first change the ID of the ssh group. That would require updating all file/folder ownerships because these are stored as GIDs (not names).

[Chuxel]

@chrmarti @bamurtaugh This just came up in microsoft/vscode-dev-containers#1493 with GID 100. The interesting thing here is that 100 is users by default, which could be an exception if that situation is detected. Generally, that's a group that is safe to add things into.

The alternative could also be to just update the UID if there's no conflicts but ignore the GID.

Others are harder, since adding a user to an existing group can have adverse side effects.

[KyleRAnderson]

I was also wondering if it's possible to update the UID even if there is a conflicting GID (and vice-versa) so that if one of them does not conflict then it gets updated. It seems that by design the update is an all or nothing action, which is unfortunate becaues in my case mentioned above, just updating the UID would probably be good enough for us to get by with.

[from-nibly]

Having this issue on nixos, by default the group that you are a part of is users and all of the files are created as owned by the group users. Because of a user roll I did a while ago. my user is 1001. Because of this the docker container skips over the entire change. I'd say the best thing to do would just be to separate the two steps.

Or is there some security concern here where you could gain root access by posing as another user when launching vsocde in the first place?

[chrmarti]

We now do update the UID if the GID already exists and in this case leave the GID unchanged.