Some extensions don't work in Firefox [Workaround]

[pickd.mask]

General info:
System is ~amd64, built with gcc-11.2.0 and glibc-2.34.
Profile: default/linux/amd64/17.1/desktop/plasma/systemd (stable)
Proprietary nvidia drivers, old (but gold) GTX-1060 6gb.
Emerge --info here: https://pastebin.com/wFn6iQj7

ATM firefox is built with the following flags and options:

[CooSee]

[pickd.mask]

Thanks for your reply.

[CooSee]

you're welcome

this is odd, because it seems resolved:

https://bugs.gentoo.org/803950

try with another user, after a restart of your system.
_________________
" Die Realität ist eine Illusion, die durch Mangel an ehrlicher Kommunikation entsteht "
---
" Der Mensch ist von Natur aus neugierig, was am Ende übrig bleibt ist die Gier "

[pickd.mask]

Using another user and fresh profile doesn't help, still same issue.

And the bug, as I understand, is only related to merging FF. And I remember that time when I had it, but that was fixed in upstream and for some time everything was fine. Until few days ago I found out that the whole "internet" changed for me: tons of ads everywhere -- because Ublock Origin stopped working.
Probably FF 92 will fix it for me, who knows.

[CooSee]

[pickd.mask]

[devsk]

So, I struggled with this one as well. Although, I could not identify the exact extension that was failing because the behavior was very odd.

Now, the question is this: Is disabling the sandbox allowing the failing extension to break some security protocols? What's the risk with running firefox with MOZ_DISABLE_CONTENT_SANDBOX=1?

Is it related to glibc-2.34? Did anyone try lower versions of glibc to confirm?

[Hu]

Assuming the sandbox is the one I think it is, then it is a system call filter that automatically kills the calling process for making a disallowed system call. The theory is that the caller has an exhaustive list of all the calls it will make when operating "properly" and the disallowed calls would only occur if a security bug allowed unauthorized code to make system calls of its choosing. In that case, disabling the sandbox is much like driving around without wearing a seat belt: as long as you don't actually crash the car (or in the Firefox case, have a security bug running unauthorized code), it's fine. If you do crash the car, the seat belt would have greatly reduced the damage you suffer in the crash. The sandbox would cause the unauthorized code to die immediately, rather than running arbitrary code to read files, make network calls, etc. Based on that, if you were using the browser in a context where you had a high level of trust in the content it is processing (say, reading HTML documents you downloaded a year ago, and keep for local reference, such as things in /usr/share/doc), I wouldn't worry much about disabling the sandbox. On the other hand, if you're using the browser in a hostile environment, like browsing the open web with Javascript enabled, I would not disable the sandbox.

This could well be related to glibc-2.34, but it's not a glibc bug. As above, the sandbox has a theoretically exhaustive list of system calls. The new glibc uses a new system call that the old sandbox doesn't know about, so the sandbox panics and kills the process. As far as I know, the glibc project never documented that they would seek the permission and cooperation of every ad-hoc sandbox project before adding new system calls to regular operation, so designing a sandbox that requires such cooperation is inherently flawed. To fix this, you need to add the new system call(s) to the sandbox allow list. For extra fun, I'm not sure if Firefox actually has a way to do that without patching its source and recompiling. Nor do I know where in the Firefox source you would go to make such a patch, if you wished to do so. Nor do I know which system calls you need to put on the allow list.

[gruftie]

[pickd.mask]

[devsk]

Something strange I can't explain...We got a glibc update today. On one system, I have the level set to 4 and it works. Made sure the env var is not set.

On another system, level has to be 2 for me to see umatrix drop down.

No idea what's going on!

[devsk]

Could the clone3 syscall be involved? https://bugs.gentoo.org/827386

[sam_]

[pickd.mask]

[devsk]

patch available at https://bugs.gentoo.org/803950

Trying it in a little bit...

Update: This works!

[Havin_it]

Well this gave me a fun 3/4 day of confusion and searching

Thank you @Hu for the really good digestible synopsis of the issue above.

I picked the option of rebuilding dev-libs/glib with USE="-fam" as it seems to have least impact on anything else; better that than putting a config in firefox or an envvar that I'll only forget about by the time the issue is resolved

Even when either firefox or glibc has this ironed out (I'm not quite sure whose job that really ought to be from reading the above), it sounds like a category of problem that could easily occur again down the line

[devsk]

Looks like this is broken again with latest glibc and latest firefox-97.0.1. The patch does not seem to help anymore.

[Hu]

In this context, what is the "latest" glibc? Latest stable (2.33), latest testing (2.34), latest no-keyword (2.35), or a -9999 ebuild? The patch was probably specific to the previous way in which the sandbox failed to account for new glibc syscalls. The latest glibc probably introduces use of yet another syscall that Firefox wrongly assumes will never be used. An strace of the dying process would likely tell us which syscall is causing problems this time.

[devsk]

I meant ~amd64, which is 2.34

[Havin_it]

For me the symptoms of breakage were different (tabs just not loading at all, instead of the more subtle breakages in bits of addon UIs) but the fix of rebuilding glib with USE="-fam" still resolves it.

[devsk]

[devsk]

Found this bug report where glib with -fam is mentioned: https://bugs.gentoo.org/828070

[Havin_it]

Yes that's it, sorry I thought it was in the bug you linked above, but forgot it was that other one that followed on from it. Glad to see you found it