chrmarti
commented
3 years ago Does the vscode user have a home folder specified in /etc/passwd?
Open branic opened 3 years ago
chrmarti
commented
3 years ago Does the vscode user have a home folder specified in /etc/passwd?
tepene
commented
3 years ago I have the same issue under Ubuntu 20.04 with podman 3.0 with the ubuntu and the node container.
Here the truncated output of /etc/passwd
$ cat /etc/passwd
...
vscode:x:1000:1000::/home/vscode:/bin/bashVSCode Version: 1.53.2 Local OS Version: Ubuntu 20.04 Remote OS Version: Ubuntu container (and node container as well) Remote Container Extension: v0.158.0 Podman Version: 3.0.0
branic
commented
3 years ago The vscode user does have an entry in /etc/passwd:
vscode:x:4400:4400::/home/vscode:/bin/bashThe home directory for the vscode user has also been created:
root ➜ / $ ls -al /home/
total 12
drwxr-xr-x 3 root root 4096 Feb 15 14:40 .
dr-xr-xr-x 23 root root 4096 Feb 15 14:44 ..
drwxr-xr-x 4 vscode vscode 4096 Feb 15 14:40 vscode
root ➜ / $ ls -al /home/vscode
total 32
drwxr-xr-x 4 vscode vscode 4096 Feb 15 14:40 .
drwxr-xr-x 3 root root 4096 Feb 15 14:40 ..
-rw-r--r-- 1 vscode vscode 220 Apr 18 2019 .bash_logout
-rw-r--r-- 1 vscode vscode 3402 Feb 1 18:05 .bashrc
drwxr-xr-x 15 vscode vscode 4096 Feb 15 14:40 .oh-my-bash
drwxr-xr-x 12 vscode vscode 4096 Feb 15 14:40 .oh-my-zsh
-rw-r--r-- 1 vscode vscode 807 Apr 18 2019 .profile
-rw-r--r-- 1 vscode vscode 3713 Feb 1 18:05 .zshrcThe logfile for rebuilding the remote container contains the line:
Start: Run: podman build -f /tmp/vsch/updateUID.Dockerfile-0.158.0 -t vsc-<XXXX>-6b90a6b25fcf980178bfcceafb62a3c5-uid --build-arg BASE_IMAGE=vsc-<XXXX>-6b90a6b25fcf980178bfcceafb62a3c5 --build-arg REMOTE_USER=vscode --build-arg NEW_UID=4400 --build-arg NEW_GID=4400 --build-arg IMAGE_USER=root /tmp/vschLooking that the /tmp/vsch/updateUID.Dockerfile-0.158.0 that is used in the that step reveals that the last step is to set the user to $IMAGE_USER which as can be seen above is set to root.
cat /tmp/vsch/updateUID.Dockerfile-0.158.0
ARG BASE_IMAGE
FROM $BASE_IMAGE
USER root
ARG REMOTE_USER
ARG NEW_UID
ARG NEW_GID
RUN /bin/sh -c ' \
eval $(sed -n "s/${REMOTE_USER}:[^:]*:\([^:]*\):\([^:]*\):[^:]*:\([^:]*\).*/OLD_UID=\1;OLD_GID=\2;HOME_FOLDER=\3/p" /etc/passwd); \
eval $(sed -n "s/\([^:]*\):[^:]*:${NEW_UID}:.*/EXISTING_USER=\1/p" /etc/passwd); \
eval $(sed -n "s/\([^:]*\):[^:]*:${NEW_GID}:.*/EXISTING_GROUP=\1/p" /etc/group); \
if [ -z "$OLD_UID" ]; then \
echo "Remote user not found in /etc/passwd ($REMOTE_USER)."; \
elif [ "$OLD_UID" = "$NEW_UID" -a "$OLD_GID" = "$NEW_GID" ]; then \
echo "UIDs and GIDs are the same ($NEW_UID:$NEW_GID)."; \
elif [ "$OLD_UID" != "$NEW_UID" -a -n "$EXISTING_USER" ]; then \
echo "User with UID exists ($EXISTING_USER=$NEW_UID)."; \
elif [ "$OLD_GID" != "$NEW_GID" -a -n "$EXISTING_GROUP" ]; then \
echo "Group with GID exists ($EXISTING_GROUP=$NEW_GID)."; \
else \
echo "Updating UID:GID from $OLD_UID:$OLD_GID to $NEW_UID:$NEW_GID."; \
sed -i -e "s/\(${REMOTE_USER}:[^:]*:\)[^:]*:[^:]*/\1${NEW_UID}:${NEW_GID}/" /etc/passwd; \
if [ "$OLD_GID" != "$NEW_GID" ]; then \
sed -i -e "s/\([^:]*:[^:]*:\)${OLD_GID}:/\1${NEW_GID}:/" /etc/group; \
fi; \
chown -R $NEW_UID:$NEW_GID $HOME_FOLDER; \
fi; \
'
ARG IMAGE_USER
USER $IMAGE_USERSo it looks like either the IMAGE_USER variable should be set to vscode in the podman build step or the Dockerfile should use the REMOTE_USER variable in the last user statement.
tepene
commented
3 years ago When I set the IMAGE_USER to vscode in the Dockerfile with
ENV IMAGE_USER vscode the container can be started but the permissions in vscode home directory are wrong. User / Group root is now the owner for all files and folders
vscode ➜ /workspaces/ansible-dev $ ls -all
total 80
drwxrwxr-x 6 root root 4096 Feb 14 17:45 .
drwxr-xr-t 5 root root 4096 Feb 15 18:39 ..
-rw-r--r-- 1 root root 82 Feb 12 10:53 ansible.cfg
drwxrwxr-x 3 root root 4096 Feb 12 10:22 .devcontainer
drwxrwxr-x 8 root root 4096 Feb 15 18:16 .git
-rw-rw-r-- 1 root root 766 Feb 12 09:33 .gitmessage
drwxr-xr-x 2 root root 4096 Feb 12 09:24 group_vars
drwxr-xr-x 2 root root 4096 Feb 12 09:24 host_vars
-rw-r--r-- 1 root root 361 Feb 12 10:52 inventory
-rw-r--r-- 1 root root 36803 Feb 12 09:19 poetry.lock
-rw-r--r-- 1 root root 390 Feb 12 10:21 pyproject.toml
-rw-r--r-- 1 root root 113 Feb 12 10:25 README.mdPodman now sets HOME to the container user's home folder. Try setting "containerUser" instead of "remoteUser".
On the updateUID.Dockerfile: The goal there is to preserve the original user, so we minimally interfere with the existing image.
Marking as upstream.
tepene
commented
3 years ago With "containerUser": "vscode" in the devcontainer.json file the container starts. But I still have the issue with the wrong permission set to root:root instead of vscode:vscode.
vscode ➜ /workspaces/ansible-dev $ ls -all
total 80
drwxrwxr-x 6 root root 4096 Feb 14 17:45 .
drwxr-xr-t 5 root root 4096 Feb 18 10:21 ..
-rw-r--r-- 1 root root 82 Feb 12 10:53 ansible.cfg
drwxrwxr-x 3 root root 4096 Feb 18 10:17 .devcontainer
drwxrwxr-x 8 root root 4096 Feb 18 10:15 .git
-rw-rw-r-- 1 root root 766 Feb 12 09:33 .gitmessage
drwxr-xr-x 2 root root 4096 Feb 12 09:24 group_vars
drwxr-xr-x 2 root root 4096 Feb 12 09:24 host_vars
-rw-r--r-- 1 root root 361 Feb 12 10:52 inventory
-rw-r--r-- 1 root root 36803 Feb 12 09:19 poetry.lock
-rw-r--r-- 1 root root 390 Feb 12 10:21 pyproject.toml
-rw-r--r-- 1 root root 113 Feb 12 10:25 README.mdI see that with Podman 2.1.1 too. The files have the user as owner on the host side, but root inside the container. This must be a Podman feature.
tepene
commented
3 years ago Maybe the container has to be launched with --userns=keep-id.
"We do recognize that this doesn't really match how many people intend to use rootless Podman - they want their UID inside and outside the container to match. Thus, we provide the --userns=keep-id flag, which ensures that your user is mapped to its own UID and GID inside the container." Source: https://github.com/containers/podman/blob/master/docs/tutorials/rootless_tutorial.md#using-volumes
chrmarti
commented
3 years ago You can add arguments to the podman run command using "runArgs" in the devcontainer.json.
tepene
commented
3 years ago et voilà ! That did the trick.
Added the two lines to the devcontainer.json
"runArgs": ["--userns=keep-id"],
"containerUser": "vscode"Now the permissions are as expected:
vscode ➜ /workspaces/ansible-dev $ ls -all
total 80
drwxrwxr-x 6 vscode vscode 4096 Feb 18 11:33 .
drwxr-xr-t 5 root root 4096 Feb 18 11:40 ..
-rw-r--r-- 1 vscode vscode 82 Feb 12 10:53 ansible.cfg
drwxrwxr-x 3 vscode vscode 4096 Feb 18 10:29 .devcontainer
drwxrwxr-x 8 vscode vscode 4096 Feb 18 11:40 .git
-rw-rw-r-- 1 vscode vscode 766 Feb 12 09:33 .gitmessage
drwxr-xr-x 2 vscode vscode 4096 Feb 12 09:24 group_vars
drwxr-xr-x 2 vscode vscode 4096 Feb 12 09:24 host_vars
-rw-r--r-- 1 vscode vscode 361 Feb 12 10:52 inventory
-rw-r--r-- 1 vscode vscode 36803 Feb 12 09:19 poetry.lock
-rw-r--r-- 1 vscode vscode 390 Feb 12 10:21 pyproject.toml
-rw-r--r-- 1 vscode vscode 113 Feb 12 10:25 README.mdMinor pitfall, the runArgs argument makes the container incompatible with a system which runs the devcontainer with docker. Launching the container with docker fails with the error docker: --userns: invalid USER mode.
branic
commented
3 years ago I just had a chance to test this as well and adding the two lines that @tepene listed works for me too.
mhazhary
commented
3 years ago Come from #5738, and use @tepene solutions. I confirm that didn't work for me. I can't even do ls, even sudo ls in the project directory.
For a note, I use node development container (16-bullseye) from Microsoft.
rapgenic
commented
2 years ago adding also "--privileged" to the runArgs seems to have fixed the problem for me.
bytzo
commented
2 years ago Would it be possible to automatically pass the --userns=keep-id flag if Podman is detected? Currently it is not possible to have a devcontainer.json file that works with both Docker and Podman (when the container user is non-root) since Docker fails with the --userns=keep-id flag.
Running Podman with PODMAN_USERNS=keep-id works the same as the --userns=keep-id and avoids Docker failing. While this is one way to support Podman in a devcontainer.json configuration, other solutions may need to be considered. See https://github.com/microsoft/vscode-remote-release/issues/4443#issuecomment-1013563654.
EirikFA
commented
2 years ago I had success using the following settings in devcontainer.json (in addition to "remoteUser": "node", which was already specified) with the 16-bullseye image:
"runArgs": [
"--userns=keep-id"
],
"containerUser": "node",
"containerEnv": {
"HOME": "/home/node"
}@EirikFA At least in my case your config snippet works with podman but fails with docker. Docker does not support --userns=keep-id
tcitworld
commented
2 years ago How would I use this in docker-compose mode, which can't use runArgs?
tesuvant
commented
2 years ago @bytzo would this work for you?
$ tail -1 /etc/containers/containers.conf
env=["BUILDAH_FORMAT=docker", "PODMAN_USERNS=keep-id"]@bytzo would this work for you?
$ tail -1 /etc/containers/containers.conf env=["BUILDAH_FORMAT=docker", "PODMAN_USERNS=keep-id"]
Using the PODMAN_USERNS variable seems to have the same effect as the --userns flag, in addition to not causing Docker to fail! Thanks for pointing this out, I wasn't aware of the option.
However, this makes me wonder how Podman support would make sense with the Remote - Containers extension. Since Podman is rootless by default, many devcontainer.json configurations meant for Docker do not work without changes (such as the default ones, see #2881). In addition to this, there is no easy way to identify which container engines a configuration is compatible with, so unexpected errors caused by using the wrong container engine may be confusing to people unfamiliar with a project. Does it make sense for the extension to automatically account for differences between different container engines? Or should devcontainer.json configurations specify compatible container engines, allowing the extension to select the correct one if installed on the system? There are many ways to go about this, however improving support for container engines other than Docker to fix issues such as this one may be outside of the scope of this issue. Shall discussion around this be taken elsewhere?
chrmarti
commented
2 years ago Looking into this I found that the rewriting of UID and GID (configured with "updateRemoteUserUID" which is on by default) of the container user to match those of the host user is part of what makes --userns=keep-id getting the dev container to work. When the container user does not have the same UID and GID as the host user --userns=keep-id adds an entry in /etc/passwd for the host user with it original name and UID which is not what we want in this case.
Another note is that "remoteUser" (used by the devcontainer.jsons we add to projects) can be used when "HOME" is set because Remote-Containers gives that precedence over the home folder it finds in /etc/passwd for the user:
"containerEnv": {
"HOME": "/home/node"
},So one possible way of improving this could be to add --userns=keep-id and ignore the HOME env variable when detecting Podman in the Remote-Containers extension.
heksesang
commented
2 years ago Wouldn't an easy fix to make this work with both podman and docker (or any other engine) be to just add the ability to set separate overrides for docker and podman in the devcontainer.json?
{
"engineOverrides": {
"docker": {
"remoteUser": "vscode"
},
"podman": {
"remoteUser": "root"
}
}
keestux
commented
2 years ago Where can I find the Git repo of remote-containers?
leeroya
commented
2 years ago containerUser
This did work for my use case, thank you @chrmarti. All I needed to do on my Mac was to set:
"containerUser": "vscode"
in the devcontainer.json
crispyricepc
commented
2 years ago @bytzo would this work for you?
$ tail -1 /etc/containers/containers.conf env=["BUILDAH_FORMAT=docker", "PODMAN_USERNS=keep-id"]
Where exactly does this need to go? I can get it to work with the flag --userns=keep-id but can't when trying to set the environment variables in this config file
lbssousa
commented
1 year ago I was able to make Dev Containers work transparenlty with Podman (no need to set "runArgs" in devcontainers.json) by providing the following settings under ${HOME}/.config/containers/containers.conf:
[containers]
env = ["BUILDAH_FORMAT=docker"] # Is this really needed?
label = false
userns = "keep-id"
p-hash
commented
1 year ago Just wanted to highlight that setting "containerUser": "vscode" does not help when I try to attach VS Code to existing running container. My user in container stays root. When I set "remoteUser": "vscode" it tries to write to /root and fails.
Let me explain my use case for that. I run Fedora Silverblue. VS Code is installed as flatpak and I want it to connect to existing toolbox container.
registry.fedoraproject.org/fedora-toolbox:37
dennybaa
commented
1 year ago Same thing I use flatpaked vscode and podman-remote (rootless configuration). Setting "remoteUser": "myuser" is required to exec into the toolbox container as a non-privileged user, while at the same time it's still perfectly possible to do so as root. The later of course it's not what we want.
Vscode sets the user and its permissions correctly to this "myuser" (Say it we make /root writable). But why on earth the extension in such a configuration tries to install and place vscode-server related stuff under /root ?
Btw the bellow settings seem to be relevant to container initialization, setting this in imageConfigs or nameConfigs give no benefits.
"runArgs": [
"--userns=keep-id"
],
"containerEnv": {
"HOME": "/home/node"
}Talking about toolbox containers, they are already initialized with --userns keep-id. So I tried both containerEnv and remoteEnv, they have no effect on an initialized container. Setting HOME is an ugly workaround, because as I mentioned we can can exec into containers under different users... So the workarounds and docs in microsoft/vs do not solve the issue, just mitigate a corner case. Attaching to a properly initialized "rootless" container doesn't work yet unfortunately.
@chrmarti Could you please reveal light if it's an expected behavior.
nathancarter
commented
1 year ago None of the tricks above worked for me. Running podman on an M1 Mac, using Microsoft Node 20-bullseye container. I've tried every subset of the above settings I can think of, but continue to get this error upon an attempt to start the container:
mkdir: cannot create directory '/root': Permission denied
Command in container failed: mkdir -p '/root/.vscode-server/bin' && ln -snf '/vscode/vscode-server/bin/linux-arm64/e7e037083ff4455cf320e344325dacb480062c3c' '/root/.vscode-server/bin/e7e037083ff4455cf320e344325dacb480062c3c'To be specific, I've heard recommendations for all of these settings:
"runArgs": [ "--userns=keep-id", "--privileged" ],
"containerUser": "node",
"containerEnv": { "HOME": "/home/node" },
"remoteUser": "node"I've tried with just some of them in various configurations, but with no success.
lachlancresswell
commented
11 months ago None of the tricks above worked for me. Running podman on an M1 Mac, using Microsoft Node 20-bullseye container. I've tried every subset of the above settings I can think of, but continue to get this error upon an attempt to start the container:
mkdir: cannot create directory '/root': Permission denied Command in container failed: mkdir -p '/root/.vscode-server/bin' && ln -snf '/vscode/vscode-server/bin/linux-arm64/e7e037083ff4455cf320e344325dacb480062c3c' '/root/.vscode-server/bin/e7e037083ff4455cf320e344325dacb480062c3c'To be specific, I've heard recommendations for all of these settings:
"runArgs": [ "--userns=keep-id", "--privileged" ], "containerUser": "node", "containerEnv": { "HOME": "/home/node" }, "remoteUser": "node"I've tried with just some of them in various configurations, but with no success.
The following from here worked for me:
"runArgs": [
"--userns=keep-id"
],
"containerEnv": {
"HOME": "/home/node"
}
Steps to Reproduce:
When the container runs it tests for the existence of and then tries to create the
.vscode-serverin therootusers directory (i.e./root/.vscode-server) instead of in the directory home directory of theremoteUser(i.e.vscode)devcontainer.json
NOTE: If I comment out the
remoteUservariable in the devcontainer.json so that the container uses therootuser, opening the project in the container is successful.Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?: No