github-starred/firejail

Fork 0

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

[GH-ISSUE #1083] Xephyr can't see abstract socket for outer X server when sandboxed #741

New issue

Closed

opened 2026-05-05 06:33:09 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 06:33:09 -06:00

Owner

Originally created by @zackw on GitHub (Jan 31, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1083

This is more of a cry for help than a coherent bug report at this point, please bear with me.

I'm experimenting with running the server processes for the various --x11 modes in their own sandboxes. These sandboxes obviously need to be able to connect to the "outer" X server. The trouble is, that server might only be listening on an abstract socket. In my testing, when Xephyr (I started with Xephyr because it's simplest) is run in a relatively straightforward sandbox with /tmp/.X11-unix whitelisted, it doesn't even try to connect to the abstract socket, it only tries the normal-namespace socket, which doesn't exist, so the call fails. If run normally it tries the abstract socket first. strace logs are unenlightening. Do you have any idea what might cause this?

Originally created by @zackw on GitHub (Jan 31, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1083 This is more of a cry for help than a coherent bug report at this point, please bear with me. I'm experimenting with running the server processes for the various `--x11` modes in their own sandboxes. These sandboxes obviously need to be able to connect to the "outer" X server. The trouble is, that server might _only_ be listening on an abstract socket. In my testing, when Xephyr (I started with Xephyr because it's simplest) is run in a relatively straightforward sandbox with `/tmp/.X11-unix` whitelisted, it doesn't even _try_ to connect to the abstract socket, it only tries the normal-namespace socket, which doesn't exist, so the call fails. If run normally it tries the abstract socket first. `strace` logs are unenlightening. Do you have any idea what might cause this?

gitea-mirror

2026-05-05 06:33:09 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:33:16 -06:00

Author

Owner

@zackw commented on GitHub (Jan 31, 2017):

On further investigation, this is caused by the mask_x11_abstract_socket logic, and the failure wasn't showing up in strace output because mask_x11_abstract_socket is implemented with a LD_PRELOAD library.

What I still don't understand is the intended semantics of FIREJAIL_X11. Setting FIREJAIL_X11=yes
enables access to the specific socket in /tmp/.X11-unix corresponding to the value of DISPLAY. But setting it to any value locks out access to all X11-related abstract sockets. What was the design goal?

@zackw commented on GitHub (Jan 31, 2017): On further investigation, this is caused by the `mask_x11_abstract_socket` logic, and the failure wasn't showing up in `strace` output because `mask_x11_abstract_socket` is implemented with a LD_PRELOAD library. What I still don't understand is the intended semantics of `FIREJAIL_X11`. Setting `FIREJAIL_X11=yes` *enables* access to the specific socket in `/tmp/.X11-unix` corresponding to the value of `DISPLAY`. But setting it to _any_ value locks out access to _all_ X11-related abstract sockets. What was the design goal?

gitea-mirror commented

2026-05-05 06:33:18 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 1, 2017):

I had to put in FIREJAIL_X11 in order to handle x11 configuration inside profile files - the logic is very convoluted, so probably I'll have to rewrite it at some point.

I(f this would help, I can disable the LD_PRELOAD library based on a flag in /etc/firejail/firejail.config.

@netblue30 commented on GitHub (Feb 1, 2017): I had to put in FIREJAIL_X11 in order to handle x11 configuration inside profile files - the logic is very convoluted, so probably I'll have to rewrite it at some point. I(f this would help, I can disable the LD_PRELOAD library based on a flag in /etc/firejail/firejail.config.

gitea-mirror commented

2026-05-05 06:33:19 -06:00

Author

Owner

@zackw commented on GitHub (Feb 1, 2017):

I am, in fact, rewriting x11.c from scratch right now. Please stay tuned for the PR. 😁

I understand you to be saying that FIREJAIL_X11's current behavior is somewhat of an accident and setting it to any value other than "yes" is not intended to be different from not setting it at all. Is that right?

@zackw commented on GitHub (Feb 1, 2017): I am, in fact, rewriting `x11.c` from scratch right now. Please stay tuned for the PR. :grin: I understand you to be saying that `FIREJAIL_X11`'s current behavior is somewhat of an accident and setting it to any value other than "yes" is not intended to be different from not setting it at all. Is that right?

gitea-mirror commented

2026-05-05 06:33:21 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 4, 2017):

Yes, that was the intention.

@netblue30 commented on GitHub (Feb 4, 2017): Yes, that was the intention.

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#741

No description provided.

Rows
Columns