[GH-ISSUE #1138] CentOS: private-tmp problems

gitea-mirror commented

2026-05-05 06:39:25 -06:00

Owner

Originally created by @msva on GitHub (Mar 10, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1138

I faced strange issue: when I trying to run firefox with .desktop-file (having Exec=firefox %u), it does not start, saying:

Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
****************************
****************************
****************************
Reading profile /etc/firejail/whitelist-common.inc
****************************
Parent pid 873978, child pid 873980
****************************
****************************
****************************
****************************
Blacklist violations are logged to syslog
Child process initialized
No protocol specified
Unable to init server: Не удалось подключиться к: В соединении отказано      ### (edit): text here means "Unable to connect to: Connection refused"
Error: cannot open display: :0

Parent is shutting down, bye...

Even if I set Terminal=1 (to run in terminal).

But when I start it from manually opened terminal window (from shell), it starts and works just fine...

Can you advice me, why can this happen?

Originally created by @msva on GitHub (Mar 10, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1138 I faced strange issue: when I trying to run firefox with .desktop-file (having `Exec=firefox %u`), it does not start, saying: ``` Reading profile /etc/firejail/firefox.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/disable-devel.inc **************************** **************************** **************************** Reading profile /etc/firejail/whitelist-common.inc **************************** Parent pid 873978, child pid 873980 **************************** **************************** **************************** **************************** Blacklist violations are logged to syslog Child process initialized No protocol specified Unable to init server: Не удалось подключиться к: В соединении отказано ### (edit): text here means "Unable to connect to: Connection refused" Error: cannot open display: :0 Parent is shutting down, bye... ``` Even if I set Terminal=1 (to run in terminal). But when I start it from manually opened terminal window (from shell), it starts and works just fine... Can you advice me, why can this happen?

gitea-mirror

2026-05-05 06:39:25 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 06:39:29 -06:00

Author

Owner

@Ferroin commented on GitHub (Mar 10, 2017):

It's probably some difference in the environment variables. When you start firejail from the terminal, it inherits all the environment from the shell you used to start it, which if it's a terminal emulator, includes both all the environment variables from the desktop environment, and all the environment variables that get set in shell startup and user login files. When you start it through a desktop file, you only get the environment variables from the desktop environment (and possibly not all of them too, depending on the DE). I'm betting it's missing something it should see in the environment variables for authentication to the X server.

@Ferroin commented on GitHub (Mar 10, 2017): It's probably some difference in the environment variables. When you start firejail from the terminal, it inherits all the environment from the shell you used to start it, which if it's a terminal emulator, includes both all the environment variables from the desktop environment, and all the environment variables that get set in shell startup and user login files. When you start it through a desktop file, you only get the environment variables from the desktop environment (and possibly not all of them too, depending on the DE). I'm betting it's missing something it should see in the environment variables for authentication to the X server.

gitea-mirror commented

2026-05-05 06:39:31 -06:00

Author

Owner

@msva commented on GitHub (Mar 10, 2017):

@Ferroin Doubt it. The only diffetence is:

--- terminal  2017-03-11 00:11:02.766729206 +0700
+++ desktop  2017-03-11 00:11:05.558627899 +0700
@@ -4,2 +3,0 @@
-BLOCKSIZE=Mb
-BROWSER=firefox
@@ -11 +9 @@
-EDITOR=vim
+EDITOR=/bin/nano
@@ -13,2 +10,0 @@
-GPG_TTY=/dev/pts/13
-GREP_COLOR=1;31
@@ -16,0 +13 @@
+GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/mva/.gtkrc-2.0:/home/mva/.config/gtkrc-2.0
@@ -18,0 +16 @@
+GTK_RC_FILES=/etc/gtk/gtkrc:/home/mva/.gtkrc:/home/mva/.config/gtkrc
@@ -21,0 +20 @@
+KDE_MULTIHEAD=false
@@ -28 +28 @@
-LANGUAGE=ru_RU.UTF-8
+LANGUAGE=ru:en_US
@@ -38 +37 @@
-PAGER=less
+PAGER=/usr/bin/less
@@ -46 +44,0 @@
-QT_QPA_PLATFORM=xcb
@@ -50 +48 @@
-SHELL_SESSION_ID=d9cbeb671c0a47d09dc940fdcc6fdc51
+SHELL_SESSION_ID=0b3e247fe5864f9990b8601818091ccf
@@ -55 +52,0 @@
-SYSTEMD_PAGER=cat
@@ -57 +53,0 @@
-TTY=/dev/pts/13
@@ -60,3 +56,2 @@
-VISUAL=vim
-WINDOWID=12582918
-XAUTHORITY=/home/mva/.Xauthority
+WINDOWID=2097158
+XAUTHORITY=/tmp/xauth-1000-_0

And, yes, I guess, you've noticed /home/mva/.Xauthority vs /tmp/xauth-1000-_0, but I checked that files and they are identical :-/

@msva commented on GitHub (Mar 10, 2017): @Ferroin Doubt it. The only diffetence is: ``` --- terminal 2017-03-11 00:11:02.766729206 +0700 +++ desktop 2017-03-11 00:11:05.558627899 +0700 @@ -4,2 +3,0 @@ -BLOCKSIZE=Mb -BROWSER=firefox @@ -11 +9 @@ -EDITOR=vim +EDITOR=/bin/nano @@ -13,2 +10,0 @@ -GPG_TTY=/dev/pts/13 -GREP_COLOR=1;31 @@ -16,0 +13 @@ +GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/mva/.gtkrc-2.0:/home/mva/.config/gtkrc-2.0 @@ -18,0 +16 @@ +GTK_RC_FILES=/etc/gtk/gtkrc:/home/mva/.gtkrc:/home/mva/.config/gtkrc @@ -21,0 +20 @@ +KDE_MULTIHEAD=false @@ -28 +28 @@ -LANGUAGE=ru_RU.UTF-8 +LANGUAGE=ru:en_US @@ -38 +37 @@ -PAGER=less +PAGER=/usr/bin/less @@ -46 +44,0 @@ -QT_QPA_PLATFORM=xcb @@ -50 +48 @@ -SHELL_SESSION_ID=d9cbeb671c0a47d09dc940fdcc6fdc51 +SHELL_SESSION_ID=0b3e247fe5864f9990b8601818091ccf @@ -55 +52,0 @@ -SYSTEMD_PAGER=cat @@ -57 +53,0 @@ -TTY=/dev/pts/13 @@ -60,3 +56,2 @@ -VISUAL=vim -WINDOWID=12582918 -XAUTHORITY=/home/mva/.Xauthority +WINDOWID=2097158 +XAUTHORITY=/tmp/xauth-1000-_0 ``` And, yes, I guess, you've noticed `/home/mva/.Xauthority` vs `/tmp/xauth-1000-_0`, but I checked that files and they are identical :-/

gitea-mirror commented

2026-05-05 06:39:33 -06:00

Author

Owner

@msva commented on GitHub (Mar 10, 2017):

Although, okay, I found the problem: firefox also (as slack) using private-tmp, and... do not copy /tmp/xauth-1000-_0 to the jail :-/

@msva commented on GitHub (Mar 10, 2017): Although, okay, I found the problem: firefox also (as slack) using `private-tmp`, and... do not copy `/tmp/xauth-1000-_0` to the jail :-/

gitea-mirror commented

2026-05-05 06:39:35 -06:00

Author

Owner

@msva commented on GitHub (Mar 11, 2017):

Uhm... I found mostly strange part of this behaviour:

if I run Fx through system menu, or even krunner it has XAUTHORITY=${HOME}/.Xauthority (just like if I run from terminal). And fj works fine.
But if I launch it from the "icons only taskbar" plasmoid, either with "run new instance" or from pinned icon, or (mostly bad part) if I trying to open http-link (which goes to xdg-open, and then to kde-open5) it gets XAUTHORITY=${TEMPDIR:-/tmp}/xinit-${USER}-${DISPLAY/:/_} value. I've found this in kde sources, but I unsure if it is the case (first of all, my kinit binary has no XAUTHORITY string inside, and secondly, the variable is defined in other cases...

So... For now, I trying to debug the issue with KDE guys (although without any luck still), but anyway, @netblue30, can you add the code to either:

copy file pointed in XAUTHORITY (but not the hardcoded ~/.Xauthority) into the jail (even in case of private-tmp)
or
support for ${XAUTHORITY} in profiles and add it to the whitelist in, at least, firefox profile?

@msva commented on GitHub (Mar 11, 2017): Uhm... I found mostly strange part of this behaviour: 1) if I run Fx through system menu, or even krunner it has `XAUTHORITY=${HOME}/.Xauthority` (just like if I run from terminal). And fj works fine. 2) But if I launch it from the "icons only taskbar" plasmoid, either with "run new instance" or from pinned icon, or (***mostly bad part***) if I trying to open http-link (which goes to xdg-open, and then to `kde-open5`) it gets `XAUTHORITY=${TEMPDIR:-/tmp}/xinit-${USER}-${DISPLAY/:/_}` value. I've found [this](https://cgit.kde.org/kinit.git/tree/src/kdeinit/kinit.cpp#n1466) in kde sources, but I unsure if it is the case (first of all, my kinit binary has no XAUTHORITY string inside, and secondly, the variable is defined in other cases... So... For now, I trying to debug the issue with KDE guys (although without any luck still), but anyway, @netblue30, can you add the code to either: 1) copy file pointed in `XAUTHORITY` (but not the hardcoded `~/.Xauthority`) into the jail (even in case of `private-tmp`) or 2) support for `${XAUTHORITY}` in profiles ***and*** add it to the whitelist in, at least, firefox profile?

gitea-mirror commented

2026-05-05 06:39:38 -06:00

Author

Owner

@msva commented on GitHub (Mar 11, 2017):

Hey @msva, may I ask which distribution you are using?

@SYN-cook Gentoo. But why?

@msva commented on GitHub (Mar 11, 2017): > Hey @msva, may I ask which distribution you are using? @SYN-cook Gentoo. But why?

gitea-mirror commented

2026-05-05 06:39:40 -06:00

Author

Owner

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

I run into the problem with private-tmp on centos a few days ago, so I removed private-tmp from the profile.

Although, okay, I found the problem: firefox also (as slack) using private-tmp, and... do not copy /tmp/xauth-1000-_0 to the jail :-/

I'll look into this, maybe I can bring back private-tmp. Thanks!

@netblue30 commented on GitHub (Mar 13, 2017): I run into the problem with private-tmp on centos a few days ago, so I removed private-tmp from the profile. > Although, okay, I found the problem: firefox also (as slack) using private-tmp, and... do not copy /tmp/xauth-1000-_0 to the jail :-/ I'll look into this, maybe I can bring back private-tmp. Thanks!

gitea-mirror commented

2026-05-05 06:39:43 -06:00

Author

Owner

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

More info from @msva

actually, it (private-tmp) produced problems not only on centos, but on many distributions (for example, it looks like KDE hardcodes /tmp/xauth-* path for XAUTHORITY for apps called in some ways (but not another),

Actually I run into it on a CentOS under KDE.

// although, even better not to /tmp/xauth-*, but ${TMPDIR:-/tmp}/xauth-${UID}-${DISPLAY/:/_} (no not expose other users sessions cookies, and another displays of current user), but I don't how to achieve this in profile...

Even if TMPDIR can be easily defaulted to /tmp if empty by firejail internals, and it is not hard to add UID/USER variables to support, it is still stays DISPLAY with the need to replace ":" with _.
Probably, it can be something like ${_DISPLAY} variable for that purpose...

Although, real fix for the issue would be to force XAUTHORITY variable inside firejail to have value of ${HOME}/.Xauthority (which, AFAIRC, firejail already copies in the jail even with private-home)

Let me try this, maybe will fix it.

@netblue30 commented on GitHub (Mar 13, 2017): More info from @msva > actually, it (private-tmp) produced problems not only on centos, but on many distributions (for example, it looks like KDE hardcodes /tmp/xauth-* path for XAUTHORITY for apps called in some ways (but not another), Actually I run into it on a CentOS under KDE. > // although, even better not to /tmp/xauth-*, but ${TMPDIR:-/tmp}/xauth-${UID}-${DISPLAY/:/_} (no not expose other users sessions cookies, and another displays of current user), but I don't how to achieve this in profile... > Even if TMPDIR can be easily defaulted to /tmp if empty by firejail internals, and it is not hard to add UID/USER variables to support, it is still stays DISPLAY with the need to replace ":" with _. Probably, it can be something like ${_DISPLAY} variable for that purpose... > Although, real fix for the issue would be to force XAUTHORITY variable inside firejail to have value of ${HOME}/.Xauthority (which, AFAIRC, firejail already copies in the jail even with private-home) Let me try this, maybe will fix it.

gitea-mirror commented

2026-05-05 06:39:47 -06:00

Author

Owner

@msva commented on GitHub (Mar 13, 2017):

By the way, I have a bit more thinking and I decided that hardcoding XAUTHORITY environment variable to ~/.Xauthority in the sources is a bad idea, since some distros can use another default path.
And it is anyway env option in firejail (although, I didn't test if it is supported in the profiles).

So, it can be added env XAUTHORITY=${HOME}/.Xauthority in default Fx profile (keeping possibility for user to redefine that).

And, better fix would be, as I suggested above, to copy the file listed in host's XAUTHORITY variable (although, also obey the value, defined with env option in profile/commandline), instead of hardcoded ~/.Xauthority.

@msva commented on GitHub (Mar 13, 2017): By the way, I have a bit more thinking and I decided that hardcoding `XAUTHORITY` environment variable to `~/.Xauthority` in the sources is a bad idea, since some distros can use another default path. And it is anyway `env` option in firejail (although, I didn't test if it is supported in the profiles). So, it can be added `env XAUTHORITY=${HOME}/.Xauthority` in default Fx profile (keeping possibility for user to redefine that). And, better fix would be, as I suggested above, to copy the file listed in host's `XAUTHORITY` variable (although, also obey the value, defined with `env` option in profile/commandline), instead of hardcoded `~/.Xauthority`.

gitea-mirror commented

2026-05-05 06:39:49 -06:00

Author

Owner

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

You are right, it is more a KDE problem than CentOS. I think it affects all KDE users. I will disable temporarily private-tmp in all profiles on 0.9.44-bugfix branch (https://github.com/netblue30/firejail/tree/0.9.44-bugfixes) and I will do a new release from this branch. The real fix will follow after that on mainline.

@netblue30 commented on GitHub (Mar 16, 2017): You are right, it is more a KDE problem than CentOS. I think it affects all KDE users. I will disable temporarily private-tmp in all profiles on 0.9.44-bugfix branch (https://github.com/netblue30/firejail/tree/0.9.44-bugfixes) and I will do a new release from this branch. The real fix will follow after that on mainline.

gitea-mirror commented

2026-05-05 06:39:52 -06:00

Author

Owner

@msva commented on GitHub (Mar 16, 2017):

By the way, I fixed it with:

$ cat ~/.config/plasma-workspace/env/fix_XAUTHORITY.sh

#!/bin/sh

T="${TMPDIR:-/tmp}"
UID=${UID:-$(id -u)}
_D="${DISPLAY//:/_}"
F="${T}/xauth-${UID}-${_D}"

truncate -s0 "${F}"
chmod a-rwx "${F}"

export XAUTHORITY="${HOME}/.Xauthority"

I just analyzed the KDE code I shared above, and found that it don't reassign
XAUTHORITY variable if can't access that file.

And I also forced in-home XAUTHORITY path just in case :)

@msva commented on GitHub (Mar 16, 2017): By the way, I fixed it with: ``` $ cat ~/.config/plasma-workspace/env/fix_XAUTHORITY.sh #!/bin/sh T="${TMPDIR:-/tmp}" UID=${UID:-$(id -u)} _D="${DISPLAY//:/_}" F="${T}/xauth-${UID}-${_D}" truncate -s0 "${F}" chmod a-rwx "${F}" export XAUTHORITY="${HOME}/.Xauthority" ``` I just analyzed the KDE code I shared above, and found that it don't reassign XAUTHORITY variable if can't access that file. And I also forced in-home XAUTHORITY path just in case :)

gitea-mirror commented

2026-05-05 06:39:54 -06:00

Author

Owner

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

Fixed on mainline, thanks for the bug!

@netblue30 commented on GitHub (Mar 22, 2017): Fixed on mainline, thanks for the bug!

Rows
Columns

[GH-ISSUE #1138] CentOS: private-tmp problems #785