FireFox snap no longer reads /usr/lib/firefox for customization

This breaks things like enterprise configuration and multi line tabs via https://github.com/Izheil/Quantum-Nox-Firefox-Dark-Full-Theme/releases

system wide stuff in snaps usually goes into $SNAP_DATA, which translates to /var/snap/<snapname>/current or $SNAP_COMMON (/var/snap/<snapname>/common).

have you tried if the FF snap perhaps could use the customization from there ?

/usr/lib/firefox has never been meant for customizations, the method advertised in that github repository looks fragile and hackish, and it means so-called customizations have to be re-applied every time firefox is updated. This definitely won’t work with firefox packaged as a snap, because snaps are immutable.

1 Like

/usr/lib/firefox is the supported folder for things like https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig (link from https://support.mozilla.org/en-US/questions/1338468)

It doesn’t need to be re-applied on apt based Firefox updates.

/usr/lib is not a supported place for modifications, overrides or configuration data in any distro, the dirs underneath it are typically exclusively for distro package data and on many enterprise systems /usr is even mounted readonly (and only made RW temporary for package updates) …

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html

local admin overrides normally go to /etc/ in linux … (in case of the firefox deb it used to go into the shipped /etc/firefox/pref/ dir which is explicitly there for overrides) …

just because the asking user in your above link used that dir for hacks it does not make it any more valid for general use …

https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson says to put it in the “Firefox install directory” not /etc.

It’s not just some random forum post.

Can you install the snap’d firefox alongside the .tar based one to ease testing ?

you likely can (i never tried) … not sure how FF will behave then though, it is a bit weird in its way of trying to re-use running instances so things might mix and mesh at runtime (and break) … you’d have to try …

--no-remote will stop that :slight_smile:

That article points to https://github.com/mozilla/policy-templates/blob/master/README.md, which says:

On Linux, the file goes into firefox/distribution, where firefox is the installation directory for firefox, which varies by distribution or you can specify system-wide policy by placing the file in /etc/firefox/policies.

The firefox snap will respect and enforce policies found in /etc/firefox/policies.

“the installation directory for firefox” would work if you had installed it locally in e.g. /opt, or directly extracted an upstream tarball somewhere under your home directory. As pointed out by @ogra, it’s really not advisable to modify files under /usr.

That and the fact that the firefox snap will store its profiles under ~/snap/firefox/common, as opposed to ~/.mozilla/firefox for an upstream tarball, means that it should mostly work. This is not really tested though.

well, i think it would make sense to allow global customization, it should be as simple as adding a layout:

layout:
[...]
    /etc/firefox/prefs:
      bind: $SNAP_COMMON/prefs

so an admin can put global modification and overrides there (assuming FF will look in /etc/firefox/prefs as the deb build did)

“have you tried if the FF snap perhaps could use the customization from there ?”

It doesn’t seem like there is a suitable folder, I think @ogra would need to get the snap updated and then it could be tested ?

Unless there somewhere to make the /var/snap/… not read only ?

Good news, can have both snap and not-snap versions side by side, just faff.

i do not maintain the firefox snap, that is done by mozilla :slight_smile: (with some help from @oSoMoN). i was just making a packaging suggestion …

this is RW by default and the place where snaps can put variable and global data as i explained above in my first post …

I’m confused. How do the places in /var/snap/… map to either /etc/firefox or /usr/lib/firefox ?

i was only reacting to your:

… it is not readonly …

When a snap package is launched snap-confine will be launched by snapd to create a “mount namespace” for the snap that allows for arbitrary mount points to be created by snap-update-ns. This is how the snap feature called “layouts” operates. The snap package can be configured at build time to request that a path e.g. in $SNAP_COMMON (i.e. /var/snap/$SNAP/common) be mounted in any other arbitrary location such as /etc/firefox. This is how a path in /var/snap can affect /etc/firefox.

Thanks for the detailed explanation @diddledani. In the case of firefox though, the snap uses the system-files interface to expose /etc/firefox/policies from the host system, rather than mounting a different path there. This is for compatibility with traditional (e.g. deb) packages.

1 Like

aha, that’s a good point. I didn’t think about the system-files interface when I was writing that… :woman_facepalming:

So are we saying it should work with policy files in /etc/firefox/policies already ?