I am running docker with user namespace remapping. The reason for this is because I want to profile my code with a tool called Intel VTune, but I can’t do it because the tool cannot profile code that is running as root. So in order to make the executables that I run inside my container not run as root, I decided to use user namespace remapping.
I added the following line to my /etc/docker/daemon.json
{
"userns-remap": "default"
}
Relevant information in this link: Isolate containers with a user namespace | Docker Docs
To summarize what this does:
- It runs docker with the
dockremapuser (docker creates this user if it’s not already present) - The
dockremapuser apparently has all the privileges that the root user has. - This means you can’t use the docker run flags
--privilegedand--net=host(“User namespace known limitations” section in the above link)
However, without the --privileged and --net=host flags, I cannot get GUI applications to run inside the container.
These are my docker run flags when running the container without user namespace remapping (so without adding the line to the /etc/docker/daemon.json).
{
"runArgs": ["--rm",
"--privileged",
"--net=host",
"--env=DISPLAY",
"--env=QT_X11_NO_MITSHM=1",
"--volume=/tmp/.X11-unix:/tmp/.X11-unix",
]
}
(Note: this is part of the devcontainer.json file for VSCode’s devcontainer extension)
With these run flags, I can run any GUI program from inside the container. Typing xhost on the terminal also works (it shows a list of all authorized users of xhost). However, the GUI program runs as root user and I cannot profile it.
When using the user namespace remapping, I simply removed the --privileged and --net=host flags.
{
"runArgs": ["--rm",
"--env=DISPLAY",
"--env=QT_X11_NO_MITSHM=1",
"--volume=/tmp/.X11-unix:/tmp/.X11-unix",
]
}
GUI applications do not work on this container. When I type xhost, it returns Unable to open display :0.
I have tried disabling the access control to XServer using xhost +. Even with the access control turned off, I could not run any GUI applications from inside the container and running xhost still returned Unable to open display :0.
I cannot pinpoint what the issue is. Since turning off access control to XServer did not fix the issue, I don’t think it is a problem with the container not being able to use the host’s XServer. I think the problem most likely arises from the lack of the --net=host flag. However, I don’t fully understand what this flag does and how to circumvent it.
Any suggestions?