ls: Operation not permitted, docker CE 24.0.2

[sputnick-dev]

Description

I have a Debian 11 image from debian:latest, I can build it as a charm.

But when I by example try as root to ls /tmp, I get:

# ls /tmp
ls: cannot access '/tmp': Operation not permitted

It's not only /tmp. I can ls only my current directory.

I searched another bug reports and the web, most of the time people try to upgrade docker and libseccomp2 (I have 2.5.1-1). I tried to get Debian sid packages, but it require to upgrade libc6 that is not a solution if I don"t want to break all my system. Any clue?

Reproduce

#!/bin/bash
docker run -d \
     --device=/dev/net/tun --cap-add=NET_ADMIN \
     -v /home/me/.config:/home/me/.config \
     -v /home/me/repository:/home/me/repository \
     -w $PWD \
     -e PVPN_USERNAME=xxx \
     -e PVPN_PASSWORD=xxx \
     --security-opt seccomp=$PWD/chrome.json \
     -v /etc/localtime:/etc/localtime:rw \
     --add-host="mongodb:172.17.0.1" \
     --user root --hostname container container

id=$(docker ps | awk '$2=="container"{print $1}')
docker container rename $id container
docker exec -u user -it container bash

Expected behavior

To be able to do by example:

ls /tmp

docker version

Client: Docker Engine - Community
 Version:           24.0.2
 API version:       1.43
 Go version:        go1.20.4
 Git commit:        cb74dfc
 Built:             Thu May 25 21:52:17 2023
 OS/Arch:           linux/amd64
 Context:           default

docker info

Client: Docker Engine - Community
 Version:    24.0.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.5
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
WARNING: Plugin "/usr/libexec/docker/cli-plugins/docker-compose" is not valid: failed to fetch metadata: exit status 1

Server:
 Containers: 1
  Running: 1

Additional Info

No response

[thaJeztah]

docker exec -u user -it container bash

So the exec is running as a (non privileged) user; what does docker exec -it container ls -la /tmp show as permissions on the /tmp directory?

This could be related to

• Different owner and permissions on /tmp in the same image on different linux hosts moby/moby#45648
• refactor(pkg/archive): factor out createImpliedDirectories helper  moby/moby#44196
• layer: clarify attributes for implied directories opencontainers/image-spec#970

[sputnick-dev]

$ docker exec -it xxx ls -la /tmp
ls: cannot access '/tmp': Operation not permitted
$ docker exec -it xxx whoami
root

[thaJeztah]

"operation not permitted" is odd. Are you seeing the same when running just a vanilla debian image (with no extra options?) are you able to narrow down what option is involved?

[sputnick-dev]

Got it, it's due to passing this file:
https://gist.github.com/sputnick-dev/4de4ae01eb18cb7d7106330c4a3e1d76

in docker run ... --security-opt seccomp=$PWD/chrome.json ...

I need it to allow me to use Selenium chromedriver from within the container.

I have this error when I don't load the file:

selenium.common.exceptions.WebDriverException: Message: unknown error: Chrome failed to start: crashed.
  (unknown error: DevToolsActivePort file doesn't exist)
  (The process started from chrome location /usr/bin/chromium is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

Tested

--security-opt seccomp=unconfined 

that works pretty well, but I don't understand security implication, not mentioned in https://docs.docker.com/engine/security/seccomp/

So finally:

#!/bin/bash
docker run -d \
     --device=/dev/net/tun --cap-add=NET_ADMIN \
     -v /home/me/.config:/home/me/.config \
     -v /home/me/repository:/home/me/repository \
     --security-opt seccomp=unconfined \
     -w $PWD \
     -e PVPN_USERNAME=xxx \
     -e PVPN_PASSWORD=xxx \
     -v /etc/localtime:/etc/localtime:rw \
     --add-host="mongodb:172.17.0.1" \
     --user root --hostname contname contname
id=$(docker ps | awk '$2=="contname"{print $1}')
docker container rename $id contname
docker exec -u me -it contname bash

ChatGPT says:

The --security-opt seccomp=unconfined option in the docker run command is used to run a container without the default seccomp profile. Seccomp is a security feature in the Linux kernel that filters system calls. It can be used to restrict the actions that a container can perform on the host system. By default, Docker uses a seccomp profile that allows only a limited set of system calls. When you use the --security-opt seccomp=unconfined option, Docker runs the container without any seccomp profile restrictions¹.

[thaJeztah]

Yes, so it seems that container may need additional syscalls that are protected by default. You could try if that's still the case (if it runs without a custom seccomp profile).

If that's not the case, it's possible it's missing a syscall that's allows by default (perhaps the custom profile is outdated), or the profile contains a syscall that's not yet supported by your kernel (docker's embedded default profile handles some conditional rules based on kernel version).

You can compare your custom profile with the default generated profile that can be found here; https://github.com/moby/moby/blob/master/profiles/seccomp/default.json

[sputnick-dev]

Sorry, but with --security-opt seccomp=$PWD/default.json from your linked JSON, I can't run my chromedriver/chromium instance:

selenium.common.exceptions.WebDriverException: Message: unknown error: Chrome failed to start: crashed.
unknown error: DevToolsActivePort file doesn't exist
The process started from chrome location /usr/bin/chromium is no longer running, so ChromeDriver is assuming that Chrome has crashed

Works well with

--security-opt seccomp=unconfined

[neersighted]

Closing for now, as this is an issue with your custom seccomp profile; our default profile is not tested against/does not claim to work with Chrome, and your profile is blocking basic functionality. You will want to compare it to the default profile, and determine what is missing.

---

Please do feel free to continue discussion here however, so that those who stumble across this issue may benefit. Also, if you do find a bug, please open it against moby/moby as that is the responsible component (the CLI merely is an API client).