github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #610] x11 support prerequisites are not fullfilled in some cases #427

New issue

Closed

opened 2026-05-05 05:50:37 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 05:50:37 -06:00

Owner

Originally created by @weeshy on GitHub (Jul 3, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/610

Starting isolated container in private-* environment is the first thing I think when become aware of firejail options. I run it console mode, and all worked fine. After that I've tried to run firejail with x11 support and it failed. After some trial and errors, I had factored permissions that are required to start xpra under firejail.

.1. /etc/xpra directory.

It stores default configuration, and that configuration has no fallback in the code. So without it xpra would be malconfigured and it could not start X server properly.

.2. ${HOME}/.xpra directory.

It stores the socket that xpra uses for connection between cliect and server. Could be alternated with --bind option for server and --socket-dir for client. So it is possible to create such directory on known location, possible tmpfs, and use it to pass sockets even when private or whitespace mode is enabled, and no interaction through user home directory is possible.

.3. /tmp directory

xpra uses global tmp to communicate with local clients via mmap. It is possible to communicate through bare socket, but it would give slightly blurry image. Some optimization is enabled for passing video stream through socket, and is disabled when ussing mmap. The mmap location could be alternated with mmap=path option, so it is possible to prepare tmpfs specifically for communication between firejailed xpra server and client.

.4. /etc/passwd, /etc/group files

Used to check for input and video groups membership, which is actual for 3d accelerated xpra sessions. If user would like to hide full information, files may be copied and reduced to hold only relevant user and groups

.5. /etc/fonts directory

Fontconfig is not requires but is very welcome to make fonts looks not so ugly

.6. /etc/bumblebee, /etc/nvidia directories

Actual configuration for running 3d acceleration on optimus architecture.

.7. /dev/nvidia0, /dev/nvidiactl, /dev/nvidia-modeset devices

Access is essential for running 3d acceleration with optirun command.

.8. /tmp/X11-unix directory

It is required for 3d-accelerated xpra. Virtualgl firstly spawns new X server to host GPU calculation. After that client inside firejail should connect to the spawned server and uses it to run X application with GPU support, encodes and sends to xpra. The X server should be accessed through apropriate socket inside /tmp/X11-unix directory. Abstract sockets and tcp sockets has no help when --net=none firejail option is enabled to jail application properly. In the absence of that option, abstract X11 socket with host system would be available to jailed system. That is the hardest part, because unfortunately Xorg has no option to move socket somewhere else, where it would not interfere with jailed applications.

.9. dbus dirty hack

There are systems where dbus is simply not installed or is not run. Or there may be firejail options enabled that prevents dbus communications between host and jailed system. What has a large sense when we talk about container isolation. There is a nasty thing in dbus, that made me hate that useful in general technology. Authors of the dbus library just could not imagine situation where their beloved creature is not available. Many users know nothing about this restriction, because they always have dbus running and available. But if for some reason, you have no dbus, your life would be occupied with nightmares.

So, when you start xpra, it import dbus libary. Just on import library tries to establish connection with dbus system. It fails and xpra application exits immediatly. xpra developer admitted that he just wanted to add extra possibilities for user to proxy dbus connection and he was upset with the fact that it become mandatory. No one in clear mind could suppose that such mature technology as dbus could not handle fails properly. But it is. As workaround xpra developer suggested to remove dbus support completly.

It could be done with --blacklist /usr/lib/python2.7/site-packages/xpra/x11/dbus and --blacklist /usr/lib/python2.7/site-packages/xpra/dbus firejail options. Exact xpra location depends on user distributive, so I could not suggest a hack that would work everywhere. The aforementioned locations are gentoo-specific and I could confirm that the hack works and xpra becomes happy with parts of its body dissected.

I'm not sure what to do with that information. Just put on the site as documentation and workaround, or check options on software side before start and abort with meaningful error if that options are contradictory with x11 prerequisites and shadows some essential file location, or automatically adjust options to include all prerequisites for running xpra.

Originally created by @weeshy on GitHub (Jul 3, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/610 Starting isolated container in private-\* environment is the first thing I think when become aware of firejail options. I run it console mode, and all worked fine. After that I've tried to run firejail with x11 support and it failed. After some trial and errors, I had factored permissions that are required to start xpra under firejail. .1. **`/etc/xpra` directory**. It stores default configuration, and that configuration has no fallback in the code. So without it xpra would be malconfigured and it could not start X server properly. .2. **`${HOME}/.xpra` directory**. It stores the socket that xpra uses for connection between cliect and server. Could be alternated with `--bind` option for server and `--socket-dir` for client. So it is possible to create such directory on known location, possible tmpfs, and use it to pass sockets even when _private_ or _whitespace_ mode is enabled, and no interaction through user home directory is possible. .3. **`/tmp` directory** xpra uses global tmp to communicate with local clients via mmap. It is possible to communicate through bare socket, but it would give slightly blurry image. Some optimization is enabled for passing video stream through socket, and is disabled when ussing mmap. The mmap location could be alternated with `mmap=path` option, so it is possible to prepare tmpfs specifically for communication between firejailed xpra server and client. .4. **`/etc/passwd`, `/etc/group` files** Used to check for input and video groups membership, which is actual for 3d accelerated xpra sessions. If user would like to hide full information, files may be copied and reduced to hold only relevant user and groups .5. **`/etc/fonts` directory** Fontconfig is not requires but is very welcome to make fonts looks not so ugly .6. **`/etc/bumblebee`, `/etc/nvidia` directories** Actual configuration for running 3d acceleration on optimus architecture. .7. **`/dev/nvidia0`, `/dev/nvidiactl`, `/dev/nvidia-modeset` devices** Access is essential for running 3d acceleration with `optirun` command. .8. **`/tmp/X11-unix` directory** It is required for 3d-accelerated xpra. Virtualgl firstly spawns new X server to host GPU calculation. After that client inside firejail should connect to the spawned server and uses it to run X application with GPU support, encodes and sends to xpra. The X server should be accessed through apropriate socket inside `/tmp/X11-unix` directory. Abstract sockets and tcp sockets has no help when `--net=none` firejail option is enabled to jail application properly. In the absence of that option, abstract X11 socket with host system would be available to jailed system. That is the hardest part, because unfortunately Xorg has no option to move socket somewhere else, where it would not interfere with jailed applications. .9. **dbus dirty hack** There are systems where _dbus_ is simply not installed or is not run. Or there may be _firejail_ options enabled that prevents _dbus_ communications between host and jailed system. What has a large sense when we talk about container isolation. There is a nasty thing in dbus, that made me hate that useful in general technology. Authors of the dbus library just could not imagine situation where their beloved creature is not available. Many users know nothing about this restriction, because they always have dbus running and available. But if for some reason, you have no dbus, your life would be occupied with nightmares. So, when you start xpra, it import dbus libary. Just on import library tries to establish connection with dbus system. It fails and xpra application exits immediatly. xpra developer admitted that he just wanted to add extra possibilities for user to proxy dbus connection and he was upset with the fact that it become mandatory. No one in clear mind could suppose that such mature technology as dbus could not handle fails properly. But it is. As workaround xpra developer suggested to remove dbus support completly. It could be done with `--blacklist /usr/lib/python2.7/site-packages/xpra/x11/dbus` and `--blacklist /usr/lib/python2.7/site-packages/xpra/dbus` firejail options. Exact xpra location depends on user distributive, so I could not suggest a hack that would work everywhere. The aforementioned locations are gentoo-specific and I could confirm that the hack works and xpra becomes happy with parts of its body dissected. --- I'm not sure what to do with that information. Just put on the site as documentation and workaround, or check options on software side before start and abort with meaningful error if that options are contradictory with x11 prerequisites and shadows some essential file location, or automatically adjust options to include all prerequisites for running xpra.

gitea-mirror

2026-05-05 05:50:37 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:50:44 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 3, 2016):

Xpra is started before the sandbox is created, so it is running on the real system. I'll run into all the problems you listed here when I move Xpra itself in the sandbox - probably in the development release after the current one. Thank you for taking the time to document all this, I'll keep it in mind.

@netblue30 commented on GitHub (Jul 3, 2016): Xpra is started before the sandbox is created, so it is running on the real system. I'll run into all the problems you listed here when I move Xpra itself in the sandbox - probably in the development release after the current one. Thank you for taking the time to document all this, I'll keep it in mind.

gitea-mirror referenced this issue

2026-05-05 10:04:42 -06:00

[PR #427] [MERGED] Paths fix #3616

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#427

No description provided.

Rows
Columns