ghcr.io/devcontainers/features/git:1 changes mode of /tmp to 755 causing "mkdir: cannot create directory ‘/tmp/.X11-unix’: Permission denied"

[keestux]

Adding feature ghcr.io/devcontainers/features/git:1 causes the mode of /tmp in the container to be changed to 0755.

This is my devcontainer.json

{
	"name": "myproj",
	"build": {
		"dockerfile": "Dockerfile",
		"context": ".."
	},
	"features": {
		"ghcr.io/devcontainers/features/git:1": {}
	}
}

and this is the Dockerfile

ARG VARIANT="3.11"
FROM mcr.microsoft.com/vscode/devcontainers/python:0-${VARIANT}

RUN ls -la /tmp

It might also be important to mention that I'm using podman. I don't have docker at hand, so I don't know if that plays a role in this bug.

When I do a "Reopen in Container" in vscode I eventually get this error:

...
[1/3] STEP 1/2: FROM mcr.microsoft.com/vscode/devcontainers/python:0-3.11 AS dev_container_auto_added_stage_label
[1/3] STEP 2/2: RUN ls -la /tmp
total 0
drwxrwxrwt. 1 root root 36 Jun  8  2023 .
dr-xr-xr-x. 1 root root 24 Sep 13 19:23 ..
drwxr-xr-x. 1 root root  0 Jun  8  2023 build-features-src
drwxr-xr-x. 1 root root 66 Jun  8  2023 dev-container-features
--> 77f2db5530a2
...
[38726 ms] Start: Run in container: test -e /tmp/.X11-unix/X0
[38727 ms] 
[38727 ms] 
[38727 ms] Exit code 1
[38727 ms] Start: Run in container: mkdir -p '/tmp/.X11-unix'
[38729 ms] 
[38729 ms] mkdir: cannot create directory ‘/tmp/.X11-unix’: Permission denied
[38730 ms] Exit code 1
[38733 ms] Command in container failed: mkdir -p '/tmp/.X11-unix'
[38733 ms] mkdir: cannot create directory ‘/tmp/.X11-unix’: Permission denied
[38734 ms] Exit code 1

When this happens, before canceling, I can "exec" into the container from another terminal and look at /tmp in the container.

$ podman exec -t -i jovial_sutherland /bin/bash
root ➜ / $ ls -ld /tmp/
drwxr-xr-x. 1 root root 80 Sep 13 19:23 /tmp/

Somewhere/somehow the mode of /tmp got changed.

If I drop the git feature the problem does not happen.

[Kaniska244]

Hello @keestux ,

Thank you for reporting this issue. I could see that you are using a very old dev container image as the base image for your dev container mcr.microsoft.com/vscode/devcontainers/python:0-3.11. That could very well be the reason behind this issue with git feature you reported.
Would you kindly use latest images such as mcr.microsoft.com/vscode/devcontainers/python:2-3.11 or mcr.microsoft.com/vscode/devcontainers/python:2-3.11-bullseye and see if the issue persists?

[keestux]

Unfortunately that didn't make a difference.

I must say, debugging this problem is extremely difficult, at least for me it is.

[Kaniska244]

Hello @keestux,

Would you kindly share the complete log for this scenario with both show container log and show previous log options? That would be help us a great deal to investigate this further.

Also you are using python pre-built dev container image which already includes the git feature in its dev container configuration. So you shouldn’t need to install it all over again.

[keestux]

Hey @Kaniska244

I cannot (yet) show you any logging, but hold on.

What I have been doing since yesterday is to use @devcontainers/cli to go through multiple edit-build-test cycles. Instead of loading features from the web I copied a feature from the src tree of this repo and placed it in a subdirectory of the .devcontainer. I worked my way through stripping the install.sh of the "feature". The start situation is when the build container has a 1777 for /tmp. And finally ended up with an install.sh that led to a container with mode 755 for /tmp.

What I now have is this:

$ find .devcontainer
.devcontainer
.devcontainer/Dockerfile
.devcontainer/devcontainer.json
.devcontainer/features
.devcontainer/features/myfeat
.devcontainer/features/myfeat/devcontainer-feature.json
.devcontainer/features/myfeat/install.sh

The files are really small, here they are

$ cat .devcontainer/Dockerfile
# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.245.2/containers/python-3/.devcontainer/base.Dockerfile

ARG VARIANT="3.11-bullseye"
FROM mcr.microsoft.com/vscode/devcontainers/python:2-${VARIANT}
$ cat .devcontainer/devcontainer.json
{
	"name": "myproj",
	"build": {
		"dockerfile": "Dockerfile",
		"context": "..",
		"args": {
			"VARIANT": "3.11",
			"NODE_VERSION": "none"
		}
	},
	"remoteUser": "vscode",
	"features": {
	 	"./features/myfeat": {}
	}
}
$ cat .devcontainer/features/myfeat/devcontainer-feature.json
{
    "id": "myfeat",
    "version": "1.0.0",
    "name": "My Feat",
    "description": "Nothing to see here.",
    "options": {
        "installDirectlyFromGitHubRelease": {
            "type": "boolean",
            "default": true
        }
    }
}
$ cat .devcontainer/features/myfeat/install.sh
#!/usr/bin/env bash

set -e

    mkdir -p /tmp/ghcli
    pushd /tmp/ghcli
    popd
    rm -rf /tmp/ghcli

With this setup I did:

• npm install @devcontainers/cli
• npx devcontainer up --workspace-folder .
• npx devcontainer exec --workspace-folder . /bin/bash -c 'ls -ld /tmp/'

The output of the last command is:

$ npx devcontainer exec --workspace-folder . /bin/bash -c 'ls -ld /tmp/'
drwxrwxrwt. 1 root root 80 Sep 18 18:37 /tmp/

Next, delete all commands from install.sh to get

#!/usr/bin/env bash
exit 0

Rebuild the container (first cleanup the previous images and container). Run the ls again. I then get

$ npx devcontainer exec --workspace-folder . /bin/bash -c 'ls -ld /tmp/'
drwxr-xr-x. 1 root root 80 Sep 18 19:01 /tmp/

[keestux]

In the install.sh, anything written to /tmp seems to be sufficient to avoid the 755 mode. This works too:

#!/usr/bin/env bash
echo hello > /tmp/hello.txt

[keestux]

I can provide the output of the npx devcontainer up --workspace-folder .. There is no difference between the good and bad case, except if the install.sh writes something to stdout.
Let me know if you still want that log.

[Yokutto]

Hi @keestux,

I'm digging about this issue with related issues that I found. I have noted that podman is a common factor between these issues, and specifically the podman above version 5.5.0, can you please confirm if that is your case?

Maybe this isn't related to podman at all, but I find pretty weird that this started happening to me in the latest versions of podman, specially since they changed /tmp behavior on 5.6.1 and 5.5.0