github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #2142] Firefox 61.0.1.glibc2.7 Appimage with multi-process windows enabled does not successfully load pages #1450

New issue

Closed

opened 2026-05-05 08:06:49 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 08:06:49 -06:00

Owner

Originally created by @crass on GitHub (Oct 6, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2142

Using up to date master with #2141 added, the 61.0.1.glibc2.7 firefox appimage displays, with saved tabs when using a pre-existing profile. However none of the tabs load, including file:/// urls. Version 56.0.2.glibc2.3.4 works just fine. I would presume all the latest profile fixes are in master, is that a wrong assumption? Has anyone else gotten 61 non-appimage to run?

https://bintray.com/probono/AppImages/Firefox/61.0.1.glibc2.7#files

Originally created by @crass on GitHub (Oct 6, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2142 Using up to date master with #2141 added, the `61.0.1.glibc2.7` firefox appimage displays, with saved tabs when using a pre-existing profile. However none of the tabs load, including `file:///` urls. Version `56.0.2.glibc2.3.4` works just fine. I would presume all the latest profile fixes are in master, is that a wrong assumption? Has anyone else gotten 61 non-appimage to run? https://bintray.com/probono/AppImages/Firefox/61.0.1.glibc2.7#files

gitea-mirror closed this issue

2026-05-05 08:06:50 -06:00

gitea-mirror commented

2026-05-05 08:06:52 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Oct 6, 2018):

I currently have a non-appimage 62.0.3 running just fine on Debian sid/experimental with a more restrictive profile than the default (mine's here).

@chiraag-nataraj commented on GitHub (Oct 6, 2018): I currently have a non-appimage `62.0.3` running just fine on Debian sid/experimental with a more restrictive profile than the default (mine's [here](https://github.com/chiraag-nataraj/firejail-profiles)).

gitea-mirror commented

2026-05-05 08:06:53 -06:00

Author

Owner

@crass commented on GitHub (Oct 8, 2018):

I've tried the latest appimage 62.0.2 and get the same symptoms. I've disabled multi-process windows (see bottom), and now both are working as expected. Do you have multi-process windows enabled?

@crass commented on GitHub (Oct 8, 2018): I've tried the latest appimage `62.0.2` and get the same symptoms. I've [disabled multi-process windows (see bottom)](https://support.mozilla.org/en-US/questions/1167673), and now both are working as expected. Do you have multi-process windows enabled?

gitea-mirror commented

2026-05-05 08:06:53 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Oct 8, 2018):

Do you have multi-process windows enabled?

Yup, I've had it enabled since they first made it available.

@chiraag-nataraj commented on GitHub (Oct 8, 2018): > Do you have multi-process windows enabled? Yup, I've had it enabled since they first made it available.

gitea-mirror commented

2026-05-05 08:06:53 -06:00

Author

Owner

@crass commented on GitHub (Oct 8, 2018):

Ok, I've narrowed it down to this code. If I remove arg_appimage from the conditional and recompile, then the firefox appimage will load content in tabs when mutli-process windows is turned on (ie. work as expected). Basically that code is causing any specific seccomp configuration (which firefox.profile has an needs) to be thrown out and to use a default config.

@netblue30, so what was the rationale behind including appimages here? It seems that the decision was made in commit 2399e09e66, but its not clear to me why. It seems to me that appimages must not be any more strict than the corresponding non-appimage profile (the program will need all the rules of the non-appimage profile plus perhaps some permission unique to appimages).

@crass commented on GitHub (Oct 8, 2018): Ok, I've narrowed it down to [this code](https://github.com/netblue30/firejail/blob/8f788307da137d985647a69f134b7f8e88765326/src/firejail/sandbox.c#L754-L758). If I remove `arg_appimage` from the conditional and recompile, then the firefox appimage will load content in tabs when mutli-process windows is turned on (ie. work as expected). Basically that code is causing any specific `seccomp` configuration (which firefox.profile has an needs) to be thrown out and to use a default config. @netblue30, so what was the rationale behind including appimages here? It seems that the decision was made in commit 2399e09e66, but its not clear to me why. It seems to me that appimages must not be any more strict than the corresponding non-appimage profile (the program will need all the rules of the non-appimage profile plus perhaps some permission unique to appimages).

gitea-mirror commented

2026-05-05 08:06:54 -06:00

Author

Owner

@crass commented on GitHub (Oct 16, 2018):

After digging deeper, the appimage will load with enforce_filters if chroot is removed from @defaults. After straceing the appimage, it can be seen that chroot and before that capset with CAP_SYS_CHROOT is being called. It appears that the sandbox is setting up a user namespace where it is root inside the sandbox, and thus can give itself capabilities.

Does anyone have thoughts on how to solve this? I'm thinking that appimage mode should only use the default seccomp if one wasn't provided. If one was provided the user clearly wanted to use that one. Also, in the vast majority of cases, the user will specify a specific profile for an appimage because the command name matching will not generally work for appimages. So, the user provided profile will have the appropriate seccomp, which may not be as restrictive as the default seccomp.

@crass commented on GitHub (Oct 16, 2018): After digging deeper, the appimage will load with `enforce_filters` _if_ `chroot` is removed from `@defaults`. After `strace`ing the appimage, it can be seen that `chroot` and before that `capset` with `CAP_SYS_CHROOT` is being called. It appears that the sandbox is setting up a user namespace where it is root inside the sandbox, and thus can give itself capabilities. Does anyone have thoughts on how to solve this? I'm thinking that appimage mode should only use the default seccomp if one wasn't provided. If one was provided the user clearly wanted to use that one. Also, in the vast majority of cases, the user will specify a specific profile for an appimage because the command name matching will not generally work for appimages. So, the user provided profile will have the appropriate seccomp, which may not be as restrictive as the default seccomp.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1450

No description provided.

Rows
Columns