github-starred/firejail

Fork 0

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

[GH-ISSUE #1157] Closing a window using xpra sandboxing crashes the entire X server #793

New issue

Closed

opened 2026-05-05 06:51:34 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 06:51:34 -06:00

Owner

Originally created by @nullchinchilla on GitHub (Mar 24, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1157

I am using Debian testing, and currently if I use firejail to attempt jailing anything with xpra-based X11 sandboxing (say firejail --x11=xpra xterm), then the entire X server of the host crashes once I close down the jail. This happens with any program I use; before the jail finishes the jailed program works fine, but once the jailed program exits, the X server crashes.

I understand that this is a duplicate of #748, but that issue seems to not be getting any attention for such a serious problem.

Originally created by @nullchinchilla on GitHub (Mar 24, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1157 I am using Debian testing, and currently if I use firejail to attempt jailing anything with xpra-based X11 sandboxing (say `firejail --x11=xpra xterm`), then the entire X server of the host crashes once I close down the jail. This happens with any program I use; before the jail finishes the jailed program works fine, but once the jailed program exits, the X server crashes. I understand that this is a duplicate of #748, but that issue seems to not be getting any attention for such a serious problem.

gitea-mirror

2026-05-05 06:51:34 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:51:40 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 25, 2017):

Thanks, I moved to old discussion here.

@netblue30 commented on GitHub (Mar 25, 2017): Thanks, I moved to old discussion here.

gitea-mirror commented

2026-05-05 06:51:42 -06:00

Author

Owner

@dewanee commented on GitHub (Jun 22, 2017):

I have the same issue running Debian unstable + lightdm + i3wm. Any news on the bug?

@dewanee commented on GitHub (Jun 22, 2017): I have the same issue running Debian unstable + lightdm + i3wm. Any news on the bug?

gitea-mirror commented

2026-05-05 06:51:44 -06:00

Author

Owner

@xiota commented on GitHub (Jul 12, 2017):

Using Ubuntu 17.04, I also get a black screen when using xpra with firejail. Since the mouse cursor is still visible, it is clear that Xorg is still running, but that it has somehow lost the ability to render or interact with the display properly.

Even though the screen is blank (except for the mouse cursor), it is possible to blindly interact with the desktop. For instance, I am able to open a terminal and reboot. I can also get back to a login screen without rebooting by killing the Xorg process from a virtual console.

ps aux | grep Xorg
sudo kill [process id]

Similar behavior occurs when running Xorg :1, which indicates this is a problem that occurs after running multiple Xorg sessions simultaneously. A workaround is to edit /etc/xpra/xpra.conf to refer to Xvfb instead of Xorg:

# ...
xvfb = Xvfb +extension Composite -nolisten tcp -noreset \
	-auth $XAUTHORITY \
	-screen 0 5760x2560x24+32
# ...

@xiota commented on GitHub (Jul 12, 2017): Using Ubuntu 17.04, I also get a black screen when using `xpra` with `firejail`. Since the mouse cursor is still visible, it is clear that `Xorg` is still running, but that it has somehow lost the ability to render or interact with the display properly. Even though the screen is blank (except for the mouse cursor), it is possible to blindly interact with the desktop. For instance, I am able to open a terminal and `reboot`. I can also get back to a login screen without rebooting by killing the `Xorg` process from a virtual console. ps aux | grep Xorg sudo kill [process id] Similar behavior occurs when running `Xorg :1`, which indicates this is a problem that occurs after running multiple `Xorg` sessions simultaneously. A workaround is to edit `/etc/xpra/xpra.conf` to refer to `Xvfb` instead of `Xorg`: # ... xvfb = Xvfb +extension Composite -nolisten tcp -noreset \ -auth $XAUTHORITY \ -screen 0 5760x2560x24+32 # ...

gitea-mirror commented

2026-05-05 06:51:47 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 13, 2017):

I've been able to reproduce it on Debian stretch! It has something to do with the way xorg is configured. Probably we'll see this coming in other distributions as well. You need to make you user part of tty group.

$ id
uid=1000(netblue) gid=1000(netblue) groups=1000(netblue),5(tty),27(sudo)

You need to run

$ sudo usermod -a -G tty your-user-name

and logout/login for the command to take effect.

@netblue30 commented on GitHub (Jul 13, 2017): I've been able to reproduce it on Debian stretch! It has something to do with the way xorg is configured. Probably we'll see this coming in other distributions as well. You need to make you user part of tty group. ````` $ id uid=1000(netblue) gid=1000(netblue) groups=1000(netblue),5(tty),27(sudo) ````` You need to run ````` $ sudo usermod -a -G tty your-user-name ````` and logout/login for the command to take effect.

gitea-mirror commented

2026-05-05 06:51:49 -06:00

Author

Owner

@xiota commented on GitHub (Jul 17, 2017):

Have confirmed that adding user to tty groups fixes the problem... Since adding users to the tty group may be undesirable, another option is to add -novtswitch to /etc/xpra/xpra.conf...

...
xvfb = /usr/bin/Xorg -noreset -nolisten tcp \
    +extension GLX +extension RANDR +extension RENDER \
    -auth $XAUTHORITY \
    -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log \
    -configdir ${HOME}/.xpra/xorg.conf.d \
    -config /etc/xpra/xorg.conf \
    -novtswitch
...

@xiota commented on GitHub (Jul 17, 2017): Have confirmed that adding user to `tty` groups fixes the problem... Since adding users to the `tty` group may be undesirable, another option is to add `-novtswitch` to `/etc/xpra/xpra.conf`... ... xvfb = /usr/bin/Xorg -noreset -nolisten tcp \ +extension GLX +extension RANDR +extension RENDER \ -auth $XAUTHORITY \ -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log \ -configdir ${HOME}/.xpra/xorg.conf.d \ -config /etc/xpra/xorg.conf \ -novtswitch ...

gitea-mirror commented

2026-05-05 06:51:52 -06:00

Author

Owner

@hahjortland commented on GitHub (Aug 30, 2017):

It did not help to add -novtswitch in Ubuntu 16.04. Adding vt8 fixes the problem for me, though:

In /etc/xpra/xpra.conf:

xvfb=Xorg -noreset -nolisten tcp \
    +extension GLX +extension RANDR +extension RENDER \
    -auth $XAUTHORITY \
    -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log \
    -configdir ${HOME}/.xpra/xorgconfigdir \
    -config /etc/xpra/xorg.conf \
    vt8

@hahjortland commented on GitHub (Aug 30, 2017): It did not help to add `-novtswitch` in Ubuntu 16.04. Adding `vt8` fixes the problem for me, though: In `/etc/xpra/xpra.conf`: ``` xvfb=Xorg -noreset -nolisten tcp \ +extension GLX +extension RANDR +extension RENDER \ -auth $XAUTHORITY \ -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log \ -configdir ${HOME}/.xpra/xorgconfigdir \ -config /etc/xpra/xorg.conf \ vt8 ```

gitea-mirror commented

2026-05-05 06:51:53 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 24, 2018):

This seems to be an Xorg problem and there are workarounds documented here.

@chiraag-nataraj commented on GitHub (Aug 24, 2018): This seems to be an Xorg problem and there are workarounds documented here.

gitea-mirror referenced this issue

2026-05-05 10:11:08 -06:00

[PR #1427] [MERGED] Unify all profiles #3959

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

No description provided.

Rows
Columns