Development containers

Disabling user namespacing

Let’s now disable user namespacing in the Docker daemon and retry: docker run -it --rm test:latest. You should get something like this:

root@ed2f0d20f197:/# ls -aln /usr/bin/bash
-rwxr-xr-x 1 0 0 1265648 Apr 23  2023 /usr/bin/bash
root@ed2f0d20f197:/# ls -alh /usr/bin/bash
-rwxr-xr-x 1 root root 1.3M Apr 23  2023 /usr/bin/bash
root@ed2f0d20f197:/# ls -alh /home/
total 0
drwxr-xr-x 1 root     root     16 Dec 24 13:30 .
drwxr-xr-x 1 root     root      0 Dec 24 13:31 ..
drwxr-xr-x 1 dev-user dev-user 54 Dec 24 13:30 dev-user
root@ed2f0d20f197:/# ls -alhn /home/
total 0
drwxr-xr-x 1    0    0 16 Dec 24 13:30 .
drwxr-xr-x 1    0    0  0 Dec 24 13:31 ..
drwxr-xr-x 1 1000 1000 54 Dec 24 13:30 dev-user

So everything is fine. But, files created with root in the container will be owned by root outside. Files created in the container will be owned by whatever user has UID 1000 on your system (most likely you).

Problems with VSCode and devcontainers

By default, VSCode uses the root user inside the container: you will perform all your operations as root whether user namespacing is enabled or not. With user namespacing on, it’s not a big deal since everything will be mapped to the correct user. Without it, everything belongs to root which is a pain. You are also doing all your actions as root which is still weird and probably a bad idea since it may not be realistic to enforce user namespacing to all members of your team (without even thinking about open source project).

You can setup VSCode to use a different user. That will work fine without user namespacing. But with it, you UID outside the container will be whatever UID user namespacing attributed to you. So you won’t have read access to the files (unless you open read access for everybody but that’s just another bad idea). So you will be stuck and won’t be able to develop.

You could ask VScode to run the containers with the --userns host option (it’s also doable with docker compose by adding userns_mode: host to your service definition). But, since the user will be added during the build step and you can’t build your image with user ns disabled (or if it’s possible, I haven’t found how), the files of the newly added users won’t belong to it as we’ve seen earlier and VSCode won’t be able to install its server.

It turns out, VSCode has a nice feature: updateRemoteUserUID. It’s on by default and will change the UID of the user of the container (unless it’s root which must stay with UID 0) to the UID of your user. So, you can transparently create file inside or outside the container they will have the correct UID! Sadly (and despite what the doc is saying) it doesn’t seem to work for GID which will still be whatever it is in the container. But it’s still a huge step forward.

Here is the docker file I used (inside a .devcontainer folder):

FROM debian:latest

RUN apt-get update && \
    apt-get install -y passwd git

# Let’s use something that proably doesn’t exit on the system.
RUN groupadd --gid 5000 dev-user \
    && useradd --uid 5000 --gid dev-user --shell /bin/bash --create-home dev-user

RUN mkdir -p /app

USER dev-user

And the devcontainer.json (also inside the .devcontainer folder):

{
  "build": { "dockerfile": "Dockerfile" },
  "workspaceMount": "source=${localWorkspaceFolder},target=/app,type=bind",
  "workspaceFolder": "/app",
  "updateRemoteUserUID": true
}

Let’s recap:

• Enabling user namespacing: besides using root as a user for all your actions, I don’t think it’s usable. And it’s probably a bad idea (you wouldn’t do it on your host system after all) and for your team mates that don’t have user namespacing enabled it will create a security issue since they are also running everything as root on the host.
• Disabling user namespacing and using a dedicated user: thanks to VSCode and its updateRemoteUserUID feature everything will work correctly out of the box. I still think it’s better to explicitly set the UID and GID to 1000 when building the container: it’s probably the right value. Since the GID isn’t updated, it’s a very good default and will hide the internals away for most users.