[GH-ISSUE #6225] chromium: does not open unless ignoring whitelist-runuser-common.inc (hyprland)

gitea-mirror commented

2026-05-05 09:50:16 -06:00

Owner

Originally created by @variasdesign on GitHub (Feb 27, 2024).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6225

Description

Hello. I'm trying to troubleshoot why Chromium was crashing with no apparent reason. Since launching chrome from the terminal didn't print any errors, I started trying ignore directives in my chromium-common.local, I arrived to ignore include whitelist-runuser-common.inc, which lets Chromium open normally.

What exactly happens in whitelist-runuser-common.inc? When ignoring it, I get a bunch of errors Failed to connect to the bus: Failed to connect to socket /run/firejail/mnt/dbus/system: Permission denied, but otherwise I can open chromium. Thanks for any help.

Steps to Reproduce

Steps to reproduce the behavior

Run in bash LC_ALL=C firejail chromium (LC_ALL=C to get a consistent
output in English that can be understood by everybody)
Chromium immediately crashes without apparent error, only firejail cleanup mesages.

Expected behavior

Chromium opens

Actual behavior

Chromium crashes

Behavior without a profile

Opens without problems

Additional context

Also running AppArmor. Fresh Arch install running Hyprland.

Environment

Arch Linux
Firejail 0.9.72

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
- I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program

LC_ALL=C firejail chromium
Reading profile /etc/firejail/chromium.profile
Reading profile /etc/firejail/chromium-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-xdg.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Parent pid 43126, child pid 43127
Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Warning: cannot create chromium directory
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Child process initialized in 142.39 ms
Warning: an existing sandbox was detected. /usr/bin/chromium will run without any additional sandboxing features
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help' for more information.

Parent is shutting down, bye...

Output of LC_ALL=C firejail --debug /path/to/program

Originally created by @variasdesign on GitHub (Feb 27, 2024). Original GitHub issue: https://github.com/netblue30/firejail/issues/6225 ### Description Hello. I'm trying to troubleshoot why Chromium was crashing with no apparent reason. Since launching chrome from the terminal didn't print any errors, I started trying ignore directives in my chromium-common.local, I arrived to ignore include whitelist-runuser-common.inc, which lets Chromium open normally. What exactly happens in whitelist-runuser-common.inc? When ignoring it, I get a bunch of errors `Failed to connect to the bus: Failed to connect to socket /run/firejail/mnt/dbus/system: Permission denied`, but otherwise I can open chromium. Thanks for any help. ### Steps to Reproduce _Steps to reproduce the behavior_ 1. Run in bash `LC_ALL=C firejail chromium` (`LC_ALL=C` to get a consistent output in English that can be understood by everybody) 2. Chromium immediately crashes without apparent error, only firejail cleanup mesages. ### Expected behavior Chromium opens ### Actual behavior Chromium crashes ### Behavior without a profile Opens without problems ### Additional context Also running AppArmor. Fresh Arch install running Hyprland. ### Environment - Arch Linux - Firejail 0.9.72 ### Checklist  - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [x] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [ ] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages) ### Log <details> <summary>Output of <code>LC_ALL=C firejail /path/to/program</code></summary> <p> ``` LC_ALL=C firejail chromium Reading profile /etc/firejail/chromium.profile Reading profile /etc/firejail/chromium-common.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-exec.inc Reading profile /etc/firejail/disable-interpreters.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/disable-xdg.inc Reading profile /etc/firejail/whitelist-common.inc Reading profile /etc/firejail/whitelist-run-common.inc Reading profile /etc/firejail/whitelist-runuser-common.inc Reading profile /etc/firejail/whitelist-usr-share-common.inc Reading profile /etc/firejail/whitelist-var-common.inc Parent pid 43126, child pid 43127 Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set. Warning: cleaning all supplementary groups Warning: cleaning all supplementary groups Warning: cannot create chromium directory Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Warning: cleaning all supplementary groups Warning: cleaning all supplementary groups Child process initialized in 142.39 ms Warning: an existing sandbox was detected. /usr/bin/chromium will run without any additional sandboxing features chrome_crashpad_handler: --database is required Try 'chrome_crashpad_handler --help' for more information. Parent is shutting down, bye... ``` </p> </details> [Output of LC_ALL=C firejail --debug /path/to/program](https://gist.github.com/variasdesign/01ff7ff2f00213fb3a402bd84bb02d57)

gitea-mirror

2026-05-05 09:50:16 -06:00

closed this issue
added the
needinfo
label

gitea-mirror commented

2026-05-05 09:50:19 -06:00

Author

Owner

@ghost commented on GitHub (Feb 27, 2024):

Warning: an existing sandbox was detected. /usr/bin/chromium will run without any additional sandboxing features

FYI: be careful when running firejail like this. The above warning shows you used firecfg, which placed a symlink in /usr/local/bin/chromium pointing to /usr/bin/firejail for easy desktop integration. Try to avoid this doubled sandboxing by making a habit out of using firejail /full/path/to/executable instead.

@ghost commented on GitHub (Feb 27, 2024): > Warning: an existing sandbox was detected. /usr/bin/chromium will run without any additional sandboxing features FYI: be careful when running firejail like this. The above warning shows you used `firecfg`, which placed a symlink in /usr/local/bin/chromium pointing to /usr/bin/firejail for easy desktop integration. Try to avoid this `doubled sandboxing` by making a habit out of using `firejail /full/path/to/executable` instead.

gitea-mirror commented

2026-05-05 09:50:20 -06:00

Author

Owner

@variasdesign commented on GitHub (Feb 27, 2024):

Whoops, sorry about that. I usually run the applications by their symlink, I just blindly copypasted the troubleshoot commands. The problem persists, though. Thanks for the heads-up.

@variasdesign commented on GitHub (Feb 27, 2024): Whoops, sorry about that. I usually run the applications by their symlink, I just blindly copypasted the troubleshoot commands. The problem persists, though. Thanks for the heads-up.

gitea-mirror commented

2026-05-05 09:50:20 -06:00

Author

Owner

@ghost commented on GitHub (Apr 15, 2024):

Also running AppArmor. Fresh Arch install running Hyprland.

whitelist-runuser-common.inc currently takes care of whitelisting what's needed for traditional X11 and Wayland. Looks like Hyprland needs additional path(s) whitelisted. Can you determine what paths it creates in /run/user/$UID?

@ghost commented on GitHub (Apr 15, 2024): > Also running AppArmor. Fresh Arch install running Hyprland. whitelist-runuser-common.inc currently takes care of whitelisting what's needed for traditional X11 and Wayland. Looks like `Hyprland` needs additional path(s) whitelisted. Can you determine what paths it creates in `/run/user/$UID`?

gitea-mirror commented

2026-05-05 09:50:21 -06:00

Author

Owner

@variasdesign commented on GitHub (Apr 15, 2024):

Also running AppArmor. Fresh Arch install running Hyprland.

whitelist-runuser-common.inc currently takes care of whitelisting what's needed for traditional X11 and Wayland. Looks like Hyprland needs additional path(s) whitelisted. Can you determine what paths it creates in /run/user/$UID?

I'm not really sure, but it seems it doesn't create anything inside /run/user/$UID. Here is my /run/user/$UID:

drwx------ - varias 15 abr 17:15 .
drwxr-xr-x - root   15 abr 17:09 ..
drwx------ - varias 15 abr 17:09 at-spi
drwx------ - varias 15 abr 17:09 dconf
dr-x------ - varias  1 ene  1970 doc
drwx------ - varias 15 abr 17:09 gcr
drwx------ - varias 15 abr 17:09 gnupg
drwxr-xr-x - varias 15 abr 17:09 p11-kit
drwxr-x--- - varias 15 abr 17:09 polychromatic
drwxr-xr-x - varias 15 abr 17:09 psd
drwx------ - varias 15 abr 17:09 pulse
drwxr-x--- - varias 15 abr 17:09 systemd
srwxr-x--- - varias 15 abr 17:09 Alacritty-wayland-1-2134.sock
srwxr-x--- - varias 15 abr 17:10 Alacritty-wayland-1-3909.sock
srwxr-x--- - varias 15 abr 17:12 Alacritty-wayland-1-5906.sock
srw-rw-rw- - varias 15 abr 17:09 bus
srwxr-x--- - varias 15 abr 17:09 fnott-wayland-1.sock
.rw-r----- 4 varias 15 abr 17:09 openrazer-daemon.pid
.rw-r----- 0 root   15 abr 17:15 pam-u2f-authpending
srw-rw-rw- - varias 15 abr 17:09 pipewire-0
srw-rw-rw- - varias 15 abr 17:09 pipewire-0-manager
.rw-r----- 0 varias 15 abr 17:09 pipewire-0-manager.lock
.rw-r----- 0 varias 15 abr 17:09 pipewire-0.lock
.rw-r----- 0 varias 15 abr 17:09 psd.pid
srw------- - varias 15 abr 17:09 ssh-agent.socket
srwxr-x--- - varias 15 abr 17:09 swww.socket
.rw------- 0 varias 15 abr 17:10 tofi.lock
srwxr-x--- - varias 15 abr 17:09 wayland-1
.rw-r----- 0 varias 15 abr 17:09 wayland-1.lock

It does, however, create a session directory inside /tmp/hypr:

drwxrwxrwt  - varias 15 abr 17:09 .
drwxrwxrwt  - root   15 abr 17:10 ..
drwxrwx---  - varias 15 abr 17:09 360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713193781
.rw-r----- 15 varias 15 abr 17:09 360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713193781.lock

Containing two sockets and a log.

Thanks for your help.

@variasdesign commented on GitHub (Apr 15, 2024): > > Also running AppArmor. Fresh Arch install running Hyprland. > > whitelist-runuser-common.inc currently takes care of whitelisting what's needed for traditional X11 and Wayland. Looks like `Hyprland` needs additional path(s) whitelisted. Can you determine what paths it creates in `/run/user/$UID`? I'm not really sure, but it seems it doesn't create anything inside `/run/user/$UID`. Here is my `/run/user/$UID`: ``` drwx------ - varias 15 abr 17:15 . drwxr-xr-x - root 15 abr 17:09 .. drwx------ - varias 15 abr 17:09 at-spi drwx------ - varias 15 abr 17:09 dconf dr-x------ - varias 1 ene 1970 doc drwx------ - varias 15 abr 17:09 gcr drwx------ - varias 15 abr 17:09 gnupg drwxr-xr-x - varias 15 abr 17:09 p11-kit drwxr-x--- - varias 15 abr 17:09 polychromatic drwxr-xr-x - varias 15 abr 17:09 psd drwx------ - varias 15 abr 17:09 pulse drwxr-x--- - varias 15 abr 17:09 systemd srwxr-x--- - varias 15 abr 17:09 Alacritty-wayland-1-2134.sock srwxr-x--- - varias 15 abr 17:10 Alacritty-wayland-1-3909.sock srwxr-x--- - varias 15 abr 17:12 Alacritty-wayland-1-5906.sock srw-rw-rw- - varias 15 abr 17:09 bus srwxr-x--- - varias 15 abr 17:09 fnott-wayland-1.sock .rw-r----- 4 varias 15 abr 17:09 openrazer-daemon.pid .rw-r----- 0 root 15 abr 17:15 pam-u2f-authpending srw-rw-rw- - varias 15 abr 17:09 pipewire-0 srw-rw-rw- - varias 15 abr 17:09 pipewire-0-manager .rw-r----- 0 varias 15 abr 17:09 pipewire-0-manager.lock .rw-r----- 0 varias 15 abr 17:09 pipewire-0.lock .rw-r----- 0 varias 15 abr 17:09 psd.pid srw------- - varias 15 abr 17:09 ssh-agent.socket srwxr-x--- - varias 15 abr 17:09 swww.socket .rw------- 0 varias 15 abr 17:10 tofi.lock srwxr-x--- - varias 15 abr 17:09 wayland-1 .rw-r----- 0 varias 15 abr 17:09 wayland-1.lock ``` It does, however, create a session directory inside `/tmp/hypr`: ``` drwxrwxrwt - varias 15 abr 17:09 . drwxrwxrwt - root 15 abr 17:10 .. drwxrwx--- - varias 15 abr 17:09 360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713193781 .rw-r----- 15 varias 15 abr 17:09 360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713193781.lock ``` Containing two sockets and a log. Thanks for your help.

gitea-mirror commented

2026-05-05 09:50:21 -06:00

Author

Owner

@ghost commented on GitHub (Apr 15, 2024):

@variasdesign
Thanks for the /run/user/$UID output. Not sure (yet) why it works when you ignore including whitelist-runuser-common.inc (wruc), this is my first encounter with hyprland. As you've noticed, we have zero support for Hyprland in Firejail currently, so until that changes you'll need to keep 'wruc' out of the chromium profiles. There might be other apps that need similar treatment.

Its sockets use is documented: https://wiki.hyprland.org/IPC/. And I understood that /usr/share/hyprland contains its configuration defaults, besides per-user ~/.config/hypr. You might want to protect those paths for now in a globals.local, although it's too early for me to give sound and tested advice on Hyprland...

@ghost commented on GitHub (Apr 15, 2024): @variasdesign Thanks for the `/run/user/$UID` output. Not sure (yet) why it works when you ignore including whitelist-runuser-common.inc (wruc), this is my first encounter with `hyprland`. As you've noticed, we have zero support for Hyprland in Firejail currently, so until that changes you'll need to keep 'wruc' out of the chromium profiles. There might be other apps that need similar treatment. Its sockets use is documented: https://wiki.hyprland.org/IPC/. And I understood that `/usr/share/hyprland` contains its configuration defaults, besides per-user `~/.config/hypr`. You might want to protect those paths for now in a globals.local, although it's too early for me to give sound and tested advice on Hyprland...

gitea-mirror commented

2026-05-05 09:50:22 -06:00

Author

Owner

@variasdesign commented on GitHub (Apr 15, 2024):

Thanks for the pointers. Poking around /run/user/$UID, I noticed the psd directory, which is created by profile-sync-daemon. The daemon mounts a tmpfs directory to speed up browser performance. I just needed to whitelist ${RUNUSER}/psd and it works now. I didn't notice until now because Firefox, which is my main browser, apparently works without any problems whatsoever without whitelisting psd.

Its sockets use is documented: https://wiki.hyprland.org/IPC/. And I understood that /usr/share/hyprland contains its configuration defaults, besides per-user ~/.config/hypr. You might want to protect those paths for now in a globals.local, although it's too early for me to give sound and tested advice on Hyprland...

How would I go about protecting those paths? Thank you.

@variasdesign commented on GitHub (Apr 15, 2024): Thanks for the pointers. Poking around `/run/user/$UID`, I noticed the `psd` directory, which is created by [profile-sync-daemon](https://wiki.archlinux.org/title/Profile-sync-daemon). The daemon mounts a tmpfs directory to speed up browser performance. I just needed to `whitelist ${RUNUSER}/psd` and it works now. I didn't notice until now because Firefox, which is my main browser, apparently works without any problems whatsoever without whitelisting `psd`. > Its sockets use is documented: https://wiki.hyprland.org/IPC/. And I understood that `/usr/share/hyprland` contains its configuration defaults, besides per-user `~/.config/hypr`. You might want to protect those paths for now in a globals.local, although it's too early for me to give sound and tested advice on Hyprland... How would I go about protecting those paths? Thank you.

gitea-mirror commented

2026-05-05 09:50:22 -06:00

Author

Owner

@ghost commented on GitHub (Apr 15, 2024):

How would I go about protecting those paths?

Most of the profiles include globals.local to offer users a way to override options. So in this context you can blacklist the relevant paths in such a file:

$ cat ~/.config/firejail/globals.local
# Firejail :: persistent global definitions

# protect hyprland configuration
blacklist ${HOME}/.config/hypr
blacklist /usr/share/hyprland

That should keep these inaccessible in sandboxes.

@ghost commented on GitHub (Apr 15, 2024): How would I go about protecting those paths? Most of the profiles include `globals.local` to offer users a way to override options. So in this context you can blacklist the relevant paths in such a file: ```sh $ cat ~/.config/firejail/globals.local # Firejail :: persistent global definitions # protect hyprland configuration blacklist ${HOME}/.config/hypr blacklist /usr/share/hyprland ``` That should keep these inaccessible in sandboxes.

gitea-mirror commented

2026-05-05 09:50:23 -06:00

Author

Owner

@variasdesign commented on GitHub (Apr 15, 2024):

Thanks for the help. I've just applied the aforementioned config. Conversely, do you think I should blacklist the /tmp/hypr directory too? I don't have use for the sockets, at least for now.

@variasdesign commented on GitHub (Apr 15, 2024): Thanks for the help. I've just applied the aforementioned config. Conversely, do you think I should blacklist the `/tmp/hypr` directory too? I don't have use for the sockets, at least for now.

gitea-mirror commented

2026-05-05 09:50:23 -06:00

Author

Owner

@ghost commented on GitHub (Apr 15, 2024):

Very welcome. I didn't want to suggest blacklisting those hyprland sockets because I don't know how that will affect Hyprland. But if you don't experience any negative effects doing so, sure, you can add that to the globals.local too. In case something breaks, there's always the option of adding the counterpart noblacklist /tmp/hypr to another foo.local. This replicates the way Firejail internally works, on a per-user basis under ~/.config/firejail and system-wide under /etc/firejail.

HTH

@ghost commented on GitHub (Apr 15, 2024): Very welcome. I didn't want to suggest blacklisting those hyprland sockets because I don't know how that will affect Hyprland. But if you don't experience any negative effects doing so, sure, you can add that to the globals.local too. In case something breaks, there's always the option of adding the counterpart `noblacklist /tmp/hypr` to another foo.local. This replicates the way Firejail internally works, on a per-user basis under ~/.config/firejail and system-wide under /etc/firejail. HTH

Rows
Columns

[GH-ISSUE #6225] chromium: does not open unless ignoring whitelist-runuser-common.inc (hyprland) #3228

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist

Log