[GH-ISSUE #5062] firefox: theme changes are not picked up automatically

gitea-mirror commented

2026-05-05 09:31:36 -06:00

Owner

Originally created by @WhyNotHugo on GitHub (Mar 21, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5062

Firefox does not pick up gtk theme changes automatically when running under firejail, but it does when running without firejail.

Changing the gtk theme on-the-fly only works when configuring it via dconf, so in order to reproduce this, make sure that the GTK_THEME environment variable is not set and that $HOME/.config/gtk-3.0/settings.ini does not define any theme either.

To change a theme, use something like:

gsettings set org.gnome.desktop.interface gtk-theme Arc-Dark
gsettings set org.gnome.desktop.interface gtk-theme Arc-Darker

Make sure you're specifying themes that are installed locally.

$ firejail --version
firejail version 0.9.68

Compile time support:
	- always force nonewprivs support is disabled
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

$ /usr/bin/firefox --version
Mozilla Firefox 98.0.1

Originally created by @WhyNotHugo on GitHub (Mar 21, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5062 Firefox does not pick up gtk theme changes automatically when running under firejail, but it does when running _without_ firejail. Changing the gtk theme on-the-fly only works when configuring it via dconf, so in order to reproduce this, make sure that the `GTK_THEME` environment variable **is not** set and that `$HOME/.config/gtk-3.0/settings.ini` **does not** define any theme either. To change a theme, use something like: ```sh gsettings set org.gnome.desktop.interface gtk-theme Arc-Dark gsettings set org.gnome.desktop.interface gtk-theme Arc-Darker ``` Make sure you're specifying themes that are installed locally. ```console $ firejail --version firejail version 0.9.68 Compile time support: - always force nonewprivs support is disabled - AppArmor support is enabled - AppImage support is enabled - chroot support is enabled - D-BUS proxy support is enabled - file transfer support is enabled - firetunnel support is enabled - networking support is enabled - output logging is enabled - overlayfs support is disabled - private-home support is enabled - private-cache and tmpfs as user enabled - SELinux support is disabled - user namespace support is enabled - X11 sandboxing support is enabled $ /usr/bin/firefox --version Mozilla Firefox 98.0.1 ```

gitea-mirror closed this issue

2026-05-05 09:31:38 -06:00

gitea-mirror commented

2026-05-05 09:31:40 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 21, 2022):

Does dbus-user.talk org.freedesktop.portal.* fix it?

@rusty-snake commented on GitHub (Mar 21, 2022): Does `dbus-user.talk org.freedesktop.portal.*` fix it?

gitea-mirror commented

2026-05-05 09:31:41 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Mar 22, 2022):

It does not (this was already in my firefox.local).

Which portal do you think plays a part here? Keep in mind that the settings portal is likely inaccessible: https://github.com/flatpak/xdg-desktop-portal/issues/737

@WhyNotHugo commented on GitHub (Mar 22, 2022): It does not (this was already in my `firefox.local`). Which portal do you think plays a part here? Keep in mind that the settings portal is likely inaccessible: https://github.com/flatpak/xdg-desktop-portal/issues/737

gitea-mirror commented

2026-05-05 09:31:42 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 22, 2022):

Then try with ignore noroot and the above.

@rusty-snake commented on GitHub (Mar 22, 2022): Then try with `ignore noroot` and the above.

gitea-mirror commented

2026-05-05 09:31:43 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 22, 2022):

Which portal do you think plays a part here? Keep in mind that the settings portal is likely inaccessible

Firefox has code using it

https://searchfox.org/mozilla-central/rev/840881e1232f664a58b39caaae6284c7bcf121df/widget/gtk/nsLookAndFeel.cpp#1304

@rusty-snake commented on GitHub (Mar 22, 2022): > Which portal do you think plays a part here? Keep in mind that the settings portal is likely inaccessible Firefox has code using it https://searchfox.org/mozilla-central/rev/840881e1232f664a58b39caaae6284c7bcf121df/widget/gtk/nsLookAndFeel.cpp#1304

gitea-mirror commented

2026-05-05 09:31:44 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Mar 22, 2022):

https://searchfox.org/mozilla-central/rev/840881e1232f664a58b39caaae6284c7bcf121df/widget/gtk/nsLookAndFeel.cpp#1304

Yup, that's the portal affected by https://github.com/flatpak/xdg-desktop-portal/issues/737. I'm working on a fix for that.

@WhyNotHugo commented on GitHub (Mar 22, 2022): > https://searchfox.org/mozilla-central/rev/840881e1232f664a58b39caaae6284c7bcf121df/widget/gtk/nsLookAndFeel.cpp#1304 Yup, that's the portal affected by https://github.com/flatpak/xdg-desktop-portal/issues/737. I'm working on a fix for that.

gitea-mirror commented

2026-05-05 09:31:44 -06:00

Author

Owner

@polyzen commented on GitHub (Oct 4, 2023):

Got theme changes via darkman working with:

dbus-user.talk org.freedesktop.portal.Desktop
ignore noroot

@polyzen commented on GitHub (Oct 4, 2023): Got theme changes via [darkman](https://darkman.whynothugo.nl/) working with: ``` dbus-user.talk org.freedesktop.portal.Desktop ignore noroot ```

gitea-mirror commented

2026-05-05 09:31:45 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Oct 4, 2023):

I think it's safe to close this; there seems to be a workaround.

@WhyNotHugo commented on GitHub (Oct 4, 2023): I think it's safe to close this; there seems to be a workaround.

gitea-mirror commented

2026-05-05 09:31:46 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Oct 4, 2023):

I still don't quite fully understand what ignore noroot does. The double negation does mess me up a bit.

The docs indicate that --noroot doesn't create a root user inside the namespace (but it's still a root-owned namespace, not a user-namesapce, right?).

       --noroot
              Install a user namespace with a single user - the current
              user.  root user does not exist in the new namespace. This
              option requires a Linux kernel version 3.8 or newer. The
              option is not supported for --chroot and --overlay
              configurations, or for sandboxes started as root.

So does ignore noroot... actually create a root user inside the namespace? Why does that make things work?

@WhyNotHugo commented on GitHub (Oct 4, 2023): I still don't quite fully understand what `ignore noroot` does. The double negation does mess me up a bit. The docs indicate that `--noroot` doesn't create a `root` user inside the namespace (but it's still a root-owned namespace, not a user-namesapce, right?). ``` --noroot Install a user namespace with a single user - the current user. root user does not exist in the new namespace. This option requires a Linux kernel version 3.8 or newer. The option is not supported for --chroot and --overlay configurations, or for sandboxes started as root. ``` So does `ignore noroot`... actually create a root user inside the namespace? Why does that make things work?

gitea-mirror commented

2026-05-05 09:31:47 -06:00

Author

Owner

@ghost commented on GitHub (Oct 4, 2023):

@WhyNotHugo

There's plenty of confusion on the need for ignore noroot in this context. According to what I'm seeing it's enough to allow Firefox to talk to dconf via dbus-user.talk ca.desrt.dconf. On X11 that is. The need for ignore noroot only comes into play when using dbus-user.talk org.freedesktop.portal.Desktop, due to noroot breaking GTK_USE_PORTAL=1 apparently (as mentioned here and inside /etc/firejail/firefox.profile). That's for a Wayland use case AFAICT. I never really dug any deeper to find out exactly why noroot and portals don't mix...

@ghost commented on GitHub (Oct 4, 2023): @WhyNotHugo There's plenty of confusion on the need for `ignore noroot` in this context. According to what I'm seeing it's enough to allow Firefox to talk to dconf via `dbus-user.talk ca.desrt.dconf`. On X11 that is. The need for `ignore noroot` only comes into play when using `dbus-user.talk org.freedesktop.portal.Desktop`, due to `noroot` breaking GTK_USE_PORTAL=1 apparently (as mentioned [here](https://github.com/netblue30/firejail/issues/2506#issuecomment-469047491) and inside /etc/firejail/firefox.profile). That's for a Wayland use case AFAICT. I never really dug any deeper to find out exactly why noroot and portals don't mix...

gitea-mirror commented

2026-05-05 09:31:47 -06:00

Author

Owner

@polyzen commented on GitHub (Oct 4, 2023):

The need for ignore noroot only comes into play when using dbus-user.talk org.freedesktop.portal.Desktop, due to noroot breaking GTK_USE_PORTAL=1 apparently (as mentioned here and inside /etc/firejail/firefox.profile). That's for a Wayland use case AFAICT. I never really dug any deeper to find out exactly why noroot and portals don't mix...

I'm not using Wayland yet, still on X11. Not using GTK_USE_PORTAL=1 either, not quite familiar with that.

@polyzen commented on GitHub (Oct 4, 2023): > The need for `ignore noroot` only comes into play when using `dbus-user.talk org.freedesktop.portal.Desktop`, due to `noroot` breaking GTK_USE_PORTAL=1 apparently (as mentioned [here](https://github.com/netblue30/firejail/issues/2506#issuecomment-469047491) and inside /etc/firejail/firefox.profile). That's for a Wayland use case AFAICT. I never really dug any deeper to find out exactly why noroot and portals don't mix... I'm not using Wayland yet, still on X11. Not using `GTK_USE_PORTAL=1` either, not quite familiar with that.

gitea-mirror commented

2026-05-05 09:31:47 -06:00

Author

Owner

@ghost commented on GitHub (Oct 4, 2023):

I'm not using Wayland yet, still on X11. Not using GTK_USE_PORTAL=1 either, not quite familiar with that.

@polyzen In that case, under the conditions OP stated (no GTK_THEME env var and no defined theme in $HOME/.config/gtk-3.0/settings.ini) a firejailed Firefox follows GTK theme changes, regardless of how it is changed (gsettings, GNOME tweaks, that darkman, etcetera) without ignore noroot

$ cat ~/.config/firejail/firefox.local
dbus-user.talk ca.desrt.dconf

@ghost commented on GitHub (Oct 4, 2023): > I'm not using Wayland yet, still on X11. Not using GTK_USE_PORTAL=1 either, not quite familiar with that. @polyzen In that case, under the conditions OP stated (no GTK_THEME env var and no defined theme in $HOME/.config/gtk-3.0/settings.ini) a firejailed Firefox follows GTK theme changes, regardless of how it is changed (gsettings, GNOME tweaks, that [darkman](https://darkman.whynothugo.nl/), etcetera) without ignore noroot ```sh $ cat ~/.config/firejail/firefox.local dbus-user.talk ca.desrt.dconf ```

gitea-mirror commented

2026-05-05 09:31:48 -06:00

Author

Owner

@polyzen commented on GitHub (Oct 4, 2023):

I have darkman changing my theme via xdg-desktop-portal (sorry, I should have been more detailed):
https://darkman.whynothugo.nl/#PORTAL

I don't think I've ever had gsettings set org.gnome.desktop.interface gtk-theme Adwaita-dark work, with or without firejail.
gsettings set org.gnome.desktop.interface color-scheme prefer-dark worked, but Firefox would only pick that up on startup. Can't recall if I've tried this one in combination with firejail.

@polyzen commented on GitHub (Oct 4, 2023): I have darkman changing my theme via xdg-desktop-portal (sorry, I should have been more detailed): https://darkman.whynothugo.nl/#PORTAL I don't think I've ever had `gsettings set org.gnome.desktop.interface gtk-theme Adwaita-dark` work, with or without firejail. `gsettings set org.gnome.desktop.interface color-scheme prefer-dark` worked, but Firefox would only pick that up on startup. Can't recall if I've tried this one in combination with firejail.

gitea-mirror commented

2026-05-05 09:31:48 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 7, 2023):

but it's still a root-owned namespace, not a user-namesapce, right?

Pineapples and bananas.

So does ignore noroot... actually create a root user inside the namespace?

It does not create a new user-namespace hence no additional ptrace access mode restrictions.

@rusty-snake commented on GitHub (Oct 7, 2023): > but it's still a root-owned namespace, not a user-namesapce, right? Pineapples and bananas. > So does ignore noroot... actually create a root user inside the namespace? It does not create a new user-namespace hence no additional ptrace access mode restrictions.

gitea-mirror commented

2026-05-05 09:31:49 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 10, 2023):

@WhyNotHugo on Oct 4:

I still don't quite fully understand what ignore noroot does. The double
negation does mess me up a bit.

The docs indicate that --noroot doesn't create a root user inside the
namespace (but it's still a root-owned namespace, not a user-namesapce,
right?).
       --noroot
              Install a user namespace with a single user - the current
              user.  root user does not exist in the new namespace. This
              option requires a Linux kernel version 3.8 or newer. The
              option is not supported for --chroot and --overlay
              configurations, or for sandboxes started as root.

From my understanding of this code:

It creates a new empty user namespace (with no users or groups mapped) and only
maps the current user ID and group ID inside of it.

It then also conditionally maps certain supplementary groups.

That is, other users and groups do not exist in the new user namespace.

For example, given the following "foo" directory:

# outside of firejail
drwxr-x--- user1  group1  foo

# inside firejail --noroot
drwxr-x--- nobody nobody  foo

If the current user ("user5") is part of "group1", then the "foo" directory
should be accessible outside of firejail. If "group1" does not exist in the
user namespace, then the user is not allowed to access the directory, due to
the 750 permissions.

See also uid_map and gid_map in user_namespaces(7).

So does ignore noroot... actually create a root user inside the namespace?
Why does that make things work?

That just makes firejail ignore subsequent noroot commands.

@kmk3 commented on GitHub (Oct 10, 2023): @WhyNotHugo [on Oct 4](https://github.com/netblue30/firejail/issues/5062#issuecomment-1746872151): > I still don't quite fully understand what `ignore noroot` does. The double > negation does mess me up a bit. > > The docs indicate that `--noroot` doesn't create a `root` user inside the > namespace (but it's still a root-owned namespace, not a user-namesapce, > right?). > > ``` > --noroot > Install a user namespace with a single user - the current > user. root user does not exist in the new namespace. This > option requires a Linux kernel version 3.8 or newer. The > option is not supported for --chroot and --overlay > configurations, or for sandboxes started as root. > ``` From my understanding of [this code][1]: It creates a new empty user namespace (with no users or groups mapped) and only maps the current user ID and group ID inside of it. It then also conditionally maps certain supplementary groups. That is, other users and groups do not exist in the new user namespace. For example, given the following "foo" directory: ``` # outside of firejail drwxr-x--- user1 group1 foo # inside firejail --noroot drwxr-x--- nobody nobody foo ``` If the current user ("user5") is part of "group1", then the "foo" directory should be accessible outside of firejail. If "group1" does not exist in the user namespace, then the user is not allowed to access the directory, due to the 750 permissions. See also `uid_map` and `gid_map` in `user_namespaces(7)`. > So does `ignore noroot`... actually create a root user inside the namespace? > Why does that make things work? That just makes firejail ignore subsequent `noroot` commands. [1]: https://github.com/netblue30/firejail/blob/0091caf80c7bb024facf406d229c82b505e5d28a/src/firejail/main.c#L3189-L3321

gitea-mirror commented

2026-05-05 09:31:49 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Oct 10, 2023):

From my understanding of this code:

It creates a new empty user namespace (with no users or groups mapped) and only
maps the current user ID and group ID inside of it.

It then also conditionally maps certain supplementary groups.

That is, other users and groups do not exist in the new user namespace.

For example, given the following "foo" directory:
# outside of firejail
drwxr-x--- user1  group1  foo

# inside firejail --noroot
drwxr-x--- nobody nobody  foo
If the current user ("user5") is part of "group1", then the "foo" directory
should be accessible outside of firejail. If "group1" does not exist in the
user namespace, then the user is not allowed to access the directory, due to
the 750 permissions.

See also uid_map and gid_map in user_namespaces(7).

This is a very clear explanation, thanks.

The user inside the sandbox ends up being the same one as on the host (e.g.: same UID), which explains why the xdg-desktop-portal's checks works -- because the current user owns the root of the sandbox's file-system and therefore the portal can read its contents.

That just makes firejail ignore subsequent noroot commands.

This is one of those items where I think that Firejail's interface can improve dramatically: because every time I try to reason about this, I no longer understand what's going on until I go back and read your previous explanation again.

It's just a bit of a puzzle to reason about:

The default runs as root and creates users in the sandbox.
Most profiles include noroot to negate this default behaviour into using a namespace with external users inside of it. This makes UIDs mismatch between the host and he sandbox.
We include ignore noroot to negate the above negation.

So ignore noroot could be though of as !!root, where root is the command that creates the root user (and others) inside the namespace (e.g.: the current default).

Doesn't it make more sense to remove noroot from the profiles entirely unless strictly necessary?

@WhyNotHugo commented on GitHub (Oct 10, 2023): > From my understanding of [this code](https://github.com/netblue30/firejail/blob/0091caf80c7bb024facf406d229c82b505e5d28a/src/firejail/main.c#L3189-L3321): > > It creates a new empty user namespace (with no users or groups mapped) and only > maps the current user ID and group ID inside of it. > > It then also conditionally maps certain supplementary groups. > > That is, other users and groups do not exist in the new user namespace. > > For example, given the following "foo" directory: > > ``` > # outside of firejail > drwxr-x--- user1 group1 foo > > # inside firejail --noroot > drwxr-x--- nobody nobody foo > ``` > > If the current user ("user5") is part of "group1", then the "foo" directory > should be accessible outside of firejail. If "group1" does not exist in the > user namespace, then the user is not allowed to access the directory, due to > the 750 permissions. > > See also uid_map and gid_map in user_namespaces(7). This is a very clear explanation, thanks. The user inside the sandbox ends up being the same one as on the host (e.g.: same UID), which explains why the xdg-desktop-portal's checks works -- because the current user owns the root of the sandbox's file-system and therefore the portal can read its contents. > That just makes firejail ignore subsequent noroot commands. This is one of those items where I think that Firejail's interface can improve dramatically: because every time I try to reason about this, I no longer understand what's going on until I go back and read your previous explanation again. It's just a bit of a puzzle to reason about: - The default runs as root and creates users in the sandbox. - Most profiles include `noroot` to negate this default behaviour into using a namespace with external users inside of it. This makes UIDs mismatch between the host and he sandbox. - We include `ignore noroot` to negate the above negation. So `ignore noroot` could be though of as `!!root`, where `root` is the command that creates the root user (and others) inside the namespace (e.g.: the current default). Doesn't it make more sense to remove `noroot` from the profiles entirely unless strictly necessary?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Oct 10, 2023):

The default ... creates users in the sandbox.

No. The default does not change users.

using a namespace with external users inside of it. This makes UIDs mismatch between the host and he sandbox.

No. There is no concept of external users and users are identity mapped.

The cause remains to be the ptrace access mode.

Doesn't it make more sense to remove noroot from the profiles entirely unless strictly necessary?

Does it make sense to remove [under security option here] from most profiles?

@rusty-snake commented on GitHub (Oct 10, 2023): > The default ... creates users in the sandbox. No. The default does not change users. > using a namespace with external users inside of it. This makes UIDs mismatch between the host and he sandbox. No. There is no concept of external users and users are identity mapped. The cause remains to be the ptrace access mode. > Doesn't it make more sense to remove noroot from the profiles entirely unless strictly necessary? Does it make sense to remove [under security option here] from most profiles?

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Oct 10, 2023):

(noroot discussion continued at #6048)

@kmk3 commented on GitHub (Oct 10, 2023): (`noroot` discussion continued at #6048)

Rows
Columns

[GH-ISSUE #5062] firefox: theme changes are not picked up automatically #2868