The last command fails with EACCES: permission denied, open '/srv/package.json' as SELinux denies access to package.json: SELinux is preventing node from read access on the file package.json..
From my point of view, this is a bit unexpected. Changing Dockerfiles to add labels doesn’t make sense to me. I guess labelling with container_file_t in CI once the source code gets pulled would make a bit more sense?
I mostly run systemd-nspawn containers and a few Podman containers. I don’t run any Docker containers. I do run one container that is designed to be run under Docker under Podman instead on a Fedora Linux server.
# podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ed3fb14a5e4 docker.io/library/mongo:6.0 --replSet overlea... 3 months ago Up 3 months (healthy) 27017/tcp mongo
f018308b9f25 docker.io/library/redis:6.2 redis-server --ap... 3 months ago Up 3 months 6379/tcp redis
8a0fd6a1f362 localhost/sharelatex/sharelatex:5.2.1-with-texlive-full 3 months ago Up 3 months 80/tcp sharelatex
I think Podman is better integrated into Fedora Linux. If you can run your Docker container under Podman, that might be the way to go on a Fedora Linux server. Podman is more likely to run with the “right” SELinux context for a Fedora Linux system. Running Docker containers under Podman might not always be possible, however. They are not 100% compatible.
In any case, I don’t know a whole lot about Docker. It looks like the source SELinux context it runs under differs depending on whether it is running in privileged mode or not.
On OpenShift, privileged containers are run in the spc_t (“Super Privileged Container”) domain, and unprivileged containers are run in the container_t domain. On containerd, with container-selinux installed, all containers are run in the spc_t domain, which effectively disables SELinux.
If you are trying to troubleshoot SELinux problems. The first thing you should probably confirm is what context the processes are running under. ps -eZ should work to list all running processes on the system and their source context. Then you can run sesearch --allow --source <type-context> (the type is the third part of the context that ends in _t) to see what target SELinux labels that source context can access (and the level of access such as read-only or both read and write).
Need to check. First I need to figure out how to pull from a custom registry (github.com), than how to pass a console /dev/ttyUSB0 but that should be feasible