Workspace inaccessible when docker's userns-remap is enabled

[Paradoxis]

When the userns-remap property is set in /etc/docker/daemon.json , workspace folders are mounted as read-only and are inaccessible to the user, even root is unable to change the permissions of the files or remount the volume.

The property is generally set as part of system hardening as to prevent people from escalating their privileges in the event the root filesystem is mounted. In this case, it just broke my devcontainer and left me puzzled to find out why exactly the volumes were mounting as nobody

• VSCode Version: 1.69.2
• Local OS Version: Latest Kali Linux Image
• Local chip architecture: amd64
• Reproduces in: Remote - Containers
• Name of Dev Container Definition with Issue: test

Steps to Reproduce:

1. Create a user with a high uid and gid, eg: "docker-containers" with UID 50000 and GID 50000
2. Set the userns-remap property to docker-containers in the daemon config
3. Reload the docker daemon and vscode
4. Launch a sample vscode devcontainer
5. All directories in the /workspace directory are now inaccessible

Suggested workaround:

A hint or warning would be nice, it took me almost four hours to debug the issue before I remembered I had hardened my system months ago, if there is a workaround for this it would be even better. :)

More info:

• https://docs.docker.com/engine/security/userns-remap/

[foxx]

Confirmed same (or similar) issue here.

When using userns-remap, the /home/vscode folder is always owned by root:root, even when doing chmod vscode:vscode.

The problem goes away if I remove userns-remap from daemon.json.

I think this has likely been introduced in the last 8 weeks, as I don't recall this ever being an issue a few months ago.

Additionally, if I use userns-remap=default, the problem also goes away. But if I use a specific mapping, e.g. userns-remap=admin:admin the problem comes back.

This can be reproduced by doing the following;

host$ cat /etc/docker/daemon.json
{
  "userns-remap": "default"
}

host$ docker run -t -i mcr.microsoft.com/vscode/devcontainers/python:3.10-bullseye /bin/bash
container$ ls -lah /home/vscode

host$ cat /etc/subuid
admin:1000:65536
dockremap:165536:65536

host$ cat /etc/subgid
admin:1000:65536
dockremap:165536:65536

host$ cat /etc/docker/daemon.json
{
  "userns-remap": "admin:admin"
}

host$ docker run -t -i mcr.microsoft.com/vscode/devcontainers/python:3.10-bullseye /bin/bash
container$ ls -lah /home/vscode

Super weird.

[Chuxel]

You should probably disable the logic that updates the UID/GID of the primary user in this scenario which is enabled by default. What might be happening is the UID/GID is getting sync'd with your local machine which then causes it to be remapped to something different.

Try adding "updateRemoteUserUID":false to devcontainer.json

Be aware that namspace remapping prevents things like docker-in-docker from working due to not supporting the privileged flag and you'll likely need to connect to the container as root since this is what your local files will be mounted as - there does not appear to be a way to change that unfortunately. If you use "clone repository in container volume", you won't have that issue since it doesn't use you local filesystem.