firefox: theme changes are not picked up automatically

[WhyNotHugo]

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

[rusty-snake]

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

[WhyNotHugo]

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: flatpak/xdg-desktop-portal#737

[rusty-snake]

Then try with ignore noroot and the above.

[rusty-snake]

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

[WhyNotHugo]

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

Yup, that's the portal affected by flatpak/xdg-desktop-portal#737. I'm working on a fix for that.

[polyzen]

Got theme changes via darkman working with:

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

[WhyNotHugo]

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

[WhyNotHugo]

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?

[glitsj16]

@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...

[polyzen]

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.

[glitsj16]

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

[polyzen]

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.

[rusty-snake]

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.

[kmk3]

@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.

[WhyNotHugo]

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?

[rusty-snake]

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?

[kmk3]

(noroot discussion continued at #6048)