github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #5339] Cannot unblacklist /usr/libexec in firefox-common.local #2963

New issue
Closed
opened 2026-05-05 09:37:37 -06:00 by gitea-mirror · 7 comments
gitea-mirror commented 2026-05-05 09:37:37 -06:00
Owner
Copy link

Originally created by @vinc17fr on GitHub (Aug 24, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5339

Description

In order to view some kinds of text files from Firefox (and potentially other similar web browsers), I need to run some text viewer, and GNU Emacs is the best one for me. However, with the new GNU Emacs 28 version under Debian, being able to access /usr/libexec/emacs is required, and this is currently not possible by default:

$ emacs
emacs: could not load dump file "/usr/libexec/emacs/28.1/x86_64-linux-gnu/emacs.pdmp": Permission denied

Though I could add noblacklist /usr/libexec to ~/.config/firejail/firefox.local to solve this issue, I would prefer to put everything to ~/.config/firejail/firefox-common.local, which is used by more profiles associated with web browsers. But adding noblacklist /usr/libexec there doesn't work as it is run too late (because firefox.profile includes firefox-common.profile at the end), and ignore blacklist /usr/libexec doesn't work either (for the same reason?). Moreover, whitelist /usr/libexec gives an error and whitelist /usr/libexec/emacs doesn't have any effect (due to the blacklist?).

If there is no way to unblacklist some blacklisted directory, the profiles need to be reworked to run firefox-common.local earlier; otherwise, what's the point of this so-called local customization?

Steps to Reproduce

  1. Put noblacklist /usr/libexec and ignore blacklist /usr/libexec in ~/.config/firejail/firefox-common.local (do not use other local customization). Or do not use any local customization.
  2. Run firejail --profile=firefox sh
  3. Run emacs (if GNU Emacs 28 is installed) and/or ls -ld /usr/libexec.

Expected behavior

/usr/libexec should be accessible.

Actual behavior

/usr/libexec is not accessible; ls -ld /usr/libexec outputs permissions dr-------- instead of drwxr-xr-x.

Behavior without a profile

N/A: The issue is about profile configuration.

Environment

  • Linux distribution and version: Debian/unstable
  • Firejail version (firejail --version): 0.9.70 (Debian package firejail 0.9.70-1)

Checklist

  • The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
  • I can reproduce the issue without custom modifications (e.g. globals.local).
  • The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
  • The profile (and redirect profile if exists) hasn't already been fixed upstream.
  • I have performed a short search for similar issues (to avoid opening a duplicate).
    • I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
  • I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)
Originally created by @vinc17fr on GitHub (Aug 24, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5339 ### Description In order to view some kinds of text files from Firefox (and potentially other similar web browsers), I need to run some text viewer, and GNU Emacs is the best one for me. However, with the new GNU Emacs 28 version under Debian, being able to access `/usr/libexec/emacs` is required, and this is currently not possible by default: ``` $ emacs emacs: could not load dump file "/usr/libexec/emacs/28.1/x86_64-linux-gnu/emacs.pdmp": Permission denied ``` Though I could add `noblacklist /usr/libexec` to `~/.config/firejail/firefox.local` to solve this issue, I would prefer to put everything to `~/.config/firejail/firefox-common.local`, which is used by more profiles associated with web browsers. But adding `noblacklist /usr/libexec` there doesn't work as it is run too late (because `firefox.profile` includes `firefox-common.profile` at the end), and `ignore blacklist /usr/libexec` doesn't work either (for the same reason?). Moreover, `whitelist /usr/libexec` gives an error and `whitelist /usr/libexec/emacs` doesn't have any effect (due to the blacklist?). If there is no way to unblacklist some blacklisted directory, the profiles need to be reworked to run `firefox-common.local` earlier; otherwise, what's the point of this so-called local customization? ### Steps to Reproduce 1. Put `noblacklist /usr/libexec` and `ignore blacklist /usr/libexec` in `~/.config/firejail/firefox-common.local` (do not use other local customization). Or do not use any local customization. 2. Run `firejail --profile=firefox sh` 3. Run `emacs` (if GNU Emacs 28 is installed) and/or `ls -ld /usr/libexec`. ### Expected behavior `/usr/libexec` should be accessible. ### Actual behavior `/usr/libexec` is not accessible; `ls -ld /usr/libexec` outputs permissions `dr--------` instead of `drwxr-xr-x`. ### Behavior without a profile N/A: The issue is about profile configuration. ### Environment - Linux distribution and version: Debian/unstable - Firejail version (`firejail --version`): 0.9.70 (Debian package firejail 0.9.70-1) ### Checklist - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [x] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [x] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages)
gitea-mirror 2026-05-05 09:37:37 -06:00
gitea-mirror commented 2026-05-05 09:37:40 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Aug 24, 2022):

If there is no way to unblacklist some blacklisted directory, the profiles need to be reworked to run firefox-common.local earlier; otherwise, what's the point of this so-called local customization?

We accept PR's. Although I can sympathize with your configuration issue, throwing out the baby with the bathwater seems a bit overkill IMO. Please consider this is not a bug, the recommended way works, as you state yourself. Currently we have exactly 13 other web browser profiles that include firefox-common.profile. Whether or not you're using all or some of them, if it's necessary to support your use case, the exact same workaround can be applied. Not willing to do the work is fine, but that's up to you. Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision.

The latest emacs on Arch Linux installs files to /usr/share/emacs (nothing to /usr/libexec because that's discouraged on that OS). If on Debian this dir exists as well, you need to add whitelist /usr/share/emacs to your firefox.local.

In the mean time I've counted exactly 13 other web browser profiles that include firefox-common.profile. None of them have blacklist /usr/libexec. So if you'd like to open a PR, you could move it to firejail-common and see what other collaborators think of it. This is how open-source stuff works.

<!-- gh-comment-id:1225994714 --> @ghost commented on GitHub (Aug 24, 2022): > If there is no way to unblacklist some blacklisted directory, the profiles need to be reworked to run firefox-common.local earlier; otherwise, what's the point of this so-called local customization? We accept PR's. Although I can sympathize with your configuration issue, throwing out the baby with the bathwater seems a bit overkill IMO. Please consider this is not a bug, the recommended way works, as you state yourself. Currently we have exactly 13 other web browser profiles that include firefox-common.profile. Whether or not you're using all or some of them, if it's necessary to support your use case, the exact same workaround can be applied. Not willing to do the work is fine, but that's up to you. Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision. The latest emacs on Arch Linux installs files to /usr/share/emacs (nothing to /usr/libexec because that's discouraged on that OS). If on Debian this dir exists as well, you need to add `whitelist /usr/share/emacs` to your firefox.local. In the mean time I've counted exactly 13 `other web browser profiles that include firefox-common.profile`. None of them have `blacklist /usr/libexec`. So if you'd like to open a PR, you could move it to firejail-common and see what other collaborators think of it. This is how open-source stuff works.
gitea-mirror commented 2026-05-05 09:37:41 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Aug 25, 2022):

@vinc17fr commented on Aug 24:

Description

In order to view some kinds of text files from Firefox (and potentially other
similar web browsers), I need to run some text viewer, and GNU Emacs is the
best one for me. However, with the new GNU Emacs 28 version under Debian,
being able to access /usr/libexec/emacs is required, and this is currently
not possible by default:

$ emacs
emacs: could not load dump file "/usr/libexec/emacs/28.1/x86_64-linux-gnu/emacs.pdmp": Permission denied

Though I could add noblacklist /usr/libexec to
~/.config/firejail/firefox.local to solve this issue, I would prefer to put
everything to ~/.config/firejail/firefox-common.local, which is used by
more profiles associated with web browsers. But adding noblacklist /usr/libexec there doesn't work as it is run too late (because
firefox.profile includes firefox-common.profile at the end), and ignore blacklist /usr/libexec doesn't work either (for the same reason?). Moreover,
whitelist /usr/libexec gives an error and whitelist /usr/libexec/emacs
doesn't have any effect (due to the blacklist?).

If there is no way to unblacklist some blacklisted directory, the profiles
need to be reworked to run firefox-common.local earlier; otherwise, what's
the point of this so-called local customization?

Suggestion:

Create a new profile, such as "webbrowser-common.profile" and include it in the
.local profile of every web browser that you use (note that the .local profile
is usually included before any blacklisting happens).

Then add the commands needed to allow emacs in it (or in a new
allow-emacs.profile file and include that instead).

<!-- gh-comment-id:1227091421 --> @kmk3 commented on GitHub (Aug 25, 2022): @vinc17fr commented [on Aug 24](https://github.com/netblue30/firejail/issues/5339#issue-1349557495): > ### Description > > In order to view some kinds of text files from Firefox (and potentially other > similar web browsers), I need to run some text viewer, and GNU Emacs is the > best one for me. However, with the new GNU Emacs 28 version under Debian, > being able to access `/usr/libexec/emacs` is required, and this is currently > not possible by default: > > ``` > $ emacs > emacs: could not load dump file "/usr/libexec/emacs/28.1/x86_64-linux-gnu/emacs.pdmp": Permission denied > ``` > > Though I could add `noblacklist /usr/libexec` to > `~/.config/firejail/firefox.local` to solve this issue, I would prefer to put > everything to `~/.config/firejail/firefox-common.local`, which is used by > more profiles associated with web browsers. But adding `noblacklist > /usr/libexec` there doesn't work as it is run too late (because > `firefox.profile` includes `firefox-common.profile` at the end), and `ignore > blacklist /usr/libexec` doesn't work either (for the same reason?). Moreover, > `whitelist /usr/libexec` gives an error and `whitelist /usr/libexec/emacs` > doesn't have any effect (due to the blacklist?). > > If there is no way to unblacklist some blacklisted directory, the profiles > need to be reworked to run `firefox-common.local` earlier; otherwise, what's > the point of this so-called local customization? Suggestion: Create a new profile, such as "webbrowser-common.profile" and include it in the .local profile of every web browser that you use (note that the .local profile is usually included before any blacklisting happens). Then add the commands needed to allow emacs in it (or in a new allow-emacs.profile file and include that instead).
gitea-mirror commented 2026-05-05 09:37:42 -06:00
Author
Owner
Copy link

@vinc17fr commented on GitHub (Aug 25, 2022):

Replying to the last two comments:

Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision.

It is not my decision. It is Firefox that runs Emacs (as an helper application) for text/* MIME types Firefox doesn't support, and I am not aware that one can change the profile from the sandbox (that would be a security issue). BTW, I've just seen that the problem is mentioned in this comment of Issue 3226. Now, using the "emacs" profile would not even be a good idea because my home directory would no longer be protected, in case of a security issue in Emacs that the viewed file could exploit. Ideally, Emacs should run with even more restrictions: for instance, it doesn't need to access the .mozilla directory to view the file.

Concerning /usr/share/emacs, it is already whitelisted in my firefox-common.local file (this was already needed before GNU Emacs 28, but the /usr/libexec thing is new in GNU Emacs 28).

I don't see why blacklist /usr/libexec would be specific to Firefox. IMHO, if it is there for a reason for Firefox, this should also be the case for the other web browsers (and in case some particular web browser would need to access /usr/libexec for its own use, then its particular profile should have noblacklist /usr/libexec).

Create a new profile, such as "webbrowser-common.profile" and include it in the .local profile of every web browser that you use

This is precisely what I want to avoid, because I don't want to remember to update my configuration for future web browsers I will use. BTW, firejail currently has this issue, making the web-browser profiles inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser ("opera" profile)?

It seems that firefox-common.profile contains things that are actually common to every web browser. So shouldn't firefox-common.profile actually by named webbrowser-common.profile and be included by all the web-browser profiles?

<!-- gh-comment-id:1227222435 --> @vinc17fr commented on GitHub (Aug 25, 2022): Replying to the last two comments: > Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision. It is not my decision. It is Firefox that runs Emacs (as an [helper application](https://en.wikipedia.org/wiki/Helper_application)) for `text/*` MIME types Firefox doesn't support, and I am not aware that one can change the profile from the sandbox (that would be a security issue). BTW, I've just seen that the problem is mentioned in [this comment of Issue 3226](https://github.com/netblue30/firejail/issues/3226#issuecomment-625926709). Now, using the "emacs" profile would not even be a good idea because my home directory would no longer be protected, in case of a security issue in Emacs that the viewed file could exploit. Ideally, Emacs should run with even more restrictions: for instance, it doesn't need to access the `.mozilla` directory to view the file. Concerning `/usr/share/emacs`, it is already whitelisted in my `firefox-common.local` file (this was already needed before GNU Emacs 28, but the `/usr/libexec` thing is new in GNU Emacs 28). I don't see why `blacklist /usr/libexec` would be specific to Firefox. IMHO, if it is there for a reason for Firefox, this should also be the case for the other web browsers (and in case some particular web browser would need to access `/usr/libexec` for its own use, then its particular profile should have `noblacklist /usr/libexec`). > Create a new profile, such as "webbrowser-common.profile" and include it in the .local profile of every web browser that you use This is precisely what I want to avoid, because I don't want to remember to update my configuration for **future** web browsers I will use. BTW, firejail currently has this issue, making the web-browser profiles inconsistent: why isn't `/usr/libexec` blacklisted for the Opera web browser ("opera" profile)? It seems that `firefox-common.profile` contains things that are actually common to every web browser. So shouldn't `firefox-common.profile` actually by named `webbrowser-common.profile` and be included by all the web-browser profiles?
gitea-mirror commented 2026-05-05 09:37:43 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Aug 25, 2022):

Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision.
It is not my decision. It is Firefox that runs Emacs (as an helper application) for text/* MIME types Firefox doesn't support, and I am not aware that one can change the profile from the sandbox (that would be a security issue).

I was confused by this from the beginning I guess. Personally I've never experienced any problems with text/* file handling in a sandboxed Firefox. Now I realize that's due to my settings and personal workflow. I open them in FF or save them to ${DOWNLOADS} and open them via CLI and/or GUI file manager with whatever app is needed, running in its own dedicated sandbox. It's a habit I suppose. Can you provide a link to a file somewhere you always open with emacs?

I don't see why blacklist /usr/libexec would be specific to Firefox.
This is precisely what I want to avoid, because I don't want to remember to update my configuration for future web browsers I will use. BTW, firejail currently has this issue, making the web-browser profiles inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser ("opera" profile)?

That's the thing. IMO this is a distro/packaging issue. Some use /usr/libexec, some don't. Those that do don't just put all executables that make up an application in that location, but also use /usr/bin. This is the commit that added blacklist /usr/libexec to firefox.profile (and several others). Not sure what the exact rationale was at the time.

It seems that firefox-common.profile contains things that are actually common to every web browser. So shouldn't firefox-common.profile actually by named webbrowser-common.profile and be included by all the web-browser profiles?

IMO this whole discussion hints at manageability of the profiles and where one would draw the line, which is bound to be always somewhat subjective. Sure there is overlap, and on face-value having a webbrowser-common.profile does sound attractive. I'm not against that on principle. I'm just worried about the rising complexities of the profiles in general. Tracking all the options for a specific application is becoming more complex, and cutting corners, making semantic changes IMO conveys a false sense of security, which we shouldn't take lightly.

<!-- gh-comment-id:1227500819 --> @ghost commented on GitHub (Aug 25, 2022): > Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision. It is not my decision. It is Firefox that runs Emacs (as an helper application) for text/* MIME types Firefox doesn't support, and I am not aware that one can change the profile from the sandbox (that would be a security issue). I was confused by this from the beginning I guess. Personally I've never experienced any problems with text/* file handling in a sandboxed Firefox. Now I realize that's due to my settings and personal workflow. I open them in FF or save them to ${DOWNLOADS} and open them via CLI and/or GUI file manager with whatever app is needed, running in its own dedicated sandbox. It's a habit I suppose. Can you provide a link to a file somewhere you always open with emacs? > I don't see why blacklist /usr/libexec would be specific to Firefox. > This is precisely what I want to avoid, because I don't want to remember to update my configuration for future web browsers I will use. BTW, firejail currently has this issue, making the web-browser profiles inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser ("opera" profile)? That's the thing. IMO this is a distro/packaging issue. Some use /usr/libexec, some don't. Those that do don't just put all executables that make up an application in that location, but also use /usr/bin. This is the [commit](https://github.com/netblue30/firejail/commit/459a186b2219d9c5e2c1b5e0fc82018f42a8e14e#diff-09c1e50ea6349ac2cb54a022b04679536dd44cf335cd9d933357ddcd350106b2) that added `blacklist /usr/libexec` to firefox.profile (and several others). Not sure what the exact rationale was at the time. > It seems that firefox-common.profile contains things that are actually common to every web browser. So shouldn't firefox-common.profile actually by named webbrowser-common.profile and be included by all the web-browser profiles? IMO this whole discussion hints at `manageability` of the profiles and where one would draw the line, which is bound to be always somewhat subjective. Sure there is overlap, and on face-value having a webbrowser-common.profile does sound attractive. I'm not against that on principle. I'm just worried about the rising complexities of the profiles in general. Tracking all the options for a specific application is becoming more complex, and cutting corners, making semantic changes IMO conveys a false sense of security, which we shouldn't take lightly.
gitea-mirror commented 2026-05-05 09:37:44 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Aug 25, 2022):

@vinc17fr commented on Aug 25:

Replying to the last two comments:

Besides, emacs has it's own dedicated profile and running it in the firefox
sandbox is also your decision.

It is not my decision. It is Firefox that runs Emacs (as an helper
application) for text/*
MIME types Firefox doesn't support, and I am not aware that one can change
the profile from the sandbox (that would be a security issue). BTW, I've just
seen that the problem is mentioned in this comment of Issue
3226.
Now, using the "emacs" profile would not even be a good idea because my home
directory would no longer be protected, in case of a security issue in Emacs
that the viewed file could exploit.

I'm afraid that there is currently no firejail-only solution to this that does
not involve allowing more things in the web browser profiles.

There is xdg-open, which was made precisely for this use case, though it
depends on dbus, which is a vector for potentially escaping the sandbox. But
if the main priority is to avoid managing the web browser profiles, this is
probably it.

Ideally, Emacs should run with even more restrictions: for instance, it
doesn't need to access the .mozilla directory to view the file.

Yes, but as mentioned in #3226, there is currently no way to do such a
transition in firejail. Maybe with Landlock support and a lot of work it
would be possible eventually, at least for filesystem paths.

Concerning /usr/share/emacs, it is already whitelisted in my
firefox-common.local file (this was already needed before GNU Emacs 28, but
the /usr/libexec thing is new in GNU Emacs 28).

I don't see why blacklist /usr/libexec would be specific to Firefox. IMHO,
if it is there for a reason for Firefox, this should also be the case for the
other web browsers (and in case some particular web browser would need to
access /usr/libexec for its own use, then its particular profile should
have noblacklist /usr/libexec).

BTW, firejail currently has this issue, making the web-browser profiles
inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser
("opera" profile)?

Good question. As said above, it looks like these restrictions were first
added on commit 459a186b2 ("Restrict /usr/libexec", 2021-05-19) / PR #4287.

@rusty-snake Is this something that could be added to an existing include? Or
is it something that would be its own include but isn't because it's only one
line?

Create a new profile, such as "webbrowser-common.profile" and include it in
the .local profile of every web browser that you use

This is precisely what I want to avoid, because I don't want to remember to
update my configuration for future web browsers I will use.

It seems that firefox-common.profile contains things that are actually
common to every web browser. So shouldn't firefox-common.profile actually
by named webbrowser-common.profile and be included by all the web-browser
profiles?

No; see chromium-common.profile and the profiles for TUI browsers, such as
lynx.profile. Maybe the common parts of firefox-common.profile and
chromium-common.profile could be extracted into a new profile, but @glitsj16's
comment about manageability should be noted in this case.

And even if the name were changed, it would still be included at the end of
profiles, because it's a common profile and so overrides to the common settings
should be set beforehand.

See the usual structure of a profile that includes a -common profile:

include foo.local           # user's profile-specific overrides
include globals.local       # user's global overrides 
# [...]                     # profile-specific includes/commands
include bar-common.profile  # common includes/commands for bar profiles

Additionally, note that the primary purpose of -common profiles is not user
customization, but to avoid having to repeat the same code on multiple profiles
upstream.

From the user's perspective, a -common profile can used as a common
"post-profile hook", so to speak and so maybe there could be a common
"pre-profile hook".

The question then becomes one of usability/organization/maintenance.

For example, including firefox-pre-common.profile at the beginning and
firefox-post-common.profile at the end.

Though that does not include every browser. So maybe webbrowser-common.profile
+ firefox-common.profile. Which might be too generic, as people probably use
TUI and GUI browsers in different contexts.

So use either webbrowser-tui-common.profile or webbrowser-gui-common.profile +
firefox-common.profile. Then people might want to do the same for other
profiles, such as email-common.profile.

And so on and so forth.

All of which increase complexity and potential for confusion (for example, "why
does this profile include an empty profile?").

So again, I'd go with either xdg-open or with overriding the .local for every
browser that you use.

<!-- gh-comment-id:1227577009 --> @kmk3 commented on GitHub (Aug 25, 2022): @vinc17fr commented [on Aug 25](https://github.com/netblue30/firejail/issues/5339#issuecomment-1227222435): > Replying to the last two comments: > > > Besides, emacs has it's own dedicated profile and running it in the firefox > > sandbox is also your decision. > > It is not my decision. It is Firefox that runs Emacs (as an [helper > application](https://en.wikipedia.org/wiki/Helper_application)) for `text/*` > MIME types Firefox doesn't support, and I am not aware that one can change > the profile from the sandbox (that would be a security issue). BTW, I've just > seen that the problem is mentioned in [this comment of Issue > 3226](https://github.com/netblue30/firejail/issues/3226#issuecomment-625926709). > Now, using the "emacs" profile would not even be a good idea because my home > directory would no longer be protected, in case of a security issue in Emacs > that the viewed file could exploit. I'm afraid that there is currently no firejail-only solution to this that does not involve allowing more things in the web browser profiles. There is xdg-open, which was made precisely for this use case, though it depends on dbus, which is a vector for potentially escaping the sandbox. But if the main priority is to avoid managing the web browser profiles, this is probably it. > Ideally, Emacs should run with even more restrictions: for instance, it > doesn't need to access the `.mozilla` directory to view the file. Yes, but as mentioned in #3226, there is currently no way to do such a transition in firejail. Maybe with [Landlock support][1] and a lot of work it would be possible eventually, at least for filesystem paths. > Concerning `/usr/share/emacs`, it is already whitelisted in my > `firefox-common.local` file (this was already needed before GNU Emacs 28, but > the `/usr/libexec` thing is new in GNU Emacs 28). > > I don't see why `blacklist /usr/libexec` would be specific to Firefox. IMHO, > if it is there for a reason for Firefox, this should also be the case for the > other web browsers (and in case some particular web browser would need to > access `/usr/libexec` for its own use, then its particular profile should > have `noblacklist /usr/libexec`). > BTW, firejail currently has this issue, making the web-browser profiles > inconsistent: why isn't `/usr/libexec` blacklisted for the Opera web browser > ("opera" profile)? Good question. As [said above][2], it looks like these restrictions were first added on commit 459a186b2 ("Restrict /usr/libexec", 2021-05-19) / PR #4287. @rusty-snake Is this something that could be added to an existing include? Or is it something that would be its own include but isn't because it's only one line? > > Create a new profile, such as "webbrowser-common.profile" and include it in > > the .local profile of every web browser that you use > > This is precisely what I want to avoid, because I don't want to remember to > update my configuration for **future** web browsers I will use. > It seems that `firefox-common.profile` contains things that are actually > common to every web browser. So shouldn't `firefox-common.profile` actually > by named `webbrowser-common.profile` and be included by all the web-browser > profiles? No; see chromium-common.profile and the profiles for TUI browsers, such as lynx.profile. Maybe the common parts of firefox-common.profile and chromium-common.profile could be extracted into a new profile, but @glitsj16's [comment about manageability][2] should be noted in this case. And even if the name were changed, it would still be included at the end of profiles, because it's a common profile and so overrides to the common settings should be set beforehand. See the usual structure of a profile that includes a -common profile: ``` firejail include foo.local # user's profile-specific overrides include globals.local # user's global overrides # [...] # profile-specific includes/commands include bar-common.profile # common includes/commands for bar profiles ``` Additionally, note that the primary purpose of -common profiles is not user customization, but to avoid having to repeat the same code on multiple profiles upstream. From the user's perspective, a -common profile can used as a common "post-profile hook", so to speak and so maybe there could be a common "pre-profile hook". The question then becomes one of usability/organization/maintenance. For example, including firefox-pre-common.profile at the beginning and firefox-post-common.profile at the end. Though that does not include every browser. So maybe webbrowser-common.profile \+ firefox-common.profile. Which might be too generic, as people probably use TUI and GUI browsers in different contexts. So use either webbrowser-tui-common.profile or webbrowser-gui-common.profile + firefox-common.profile. Then people might want to do the same for other profiles, such as email-common.profile. And so on and so forth. All of which increase complexity and potential for confusion (for example, "why does this profile include an empty profile?"). So again, I'd go with either xdg-open or with overriding the .local for every browser that you use. [1]: https://github.com/netblue30/firejail/issues/5269 [2]: https://github.com/netblue30/firejail/issues/5339#issuecomment-1227500819
gitea-mirror commented 2026-05-05 09:37:45 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Aug 30, 2022):

Is this something that could be added to an existing include? Or is it something that would be its own include but isn't because it's only one
line?

One line isn't a include thing. I'm even against all short includes (3-5 lines) but we don't have aliases/macros yet.

<!-- gh-comment-id:1231991764 --> @rusty-snake commented on GitHub (Aug 30, 2022): > Is this something that could be added to an existing include? Or is it something that would be its own include but isn't because it's only one line? One line isn't a include thing. I'm even against all short includes (3-5 lines) but we don't have aliases/macros yet.
gitea-mirror commented 2026-05-05 09:37:46 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Aug 31, 2022):

So as mentioned, the main purpose of firefox-common.profile is to organize
the code and whatever customization benefits it (and firefox-common.local)
provide are incidental, so marking this as "notabug".

Other ways of resolving the issue at hand were posted and there hasn't been any
more activity about the main issue for about a week, so I'm closing this.

Feel free to post any updates or request to reopen if you have more questions.

<!-- gh-comment-id:1233280377 --> @kmk3 commented on GitHub (Aug 31, 2022): So [as mentioned][1], the main purpose of firefox-common.profile is to organize the code and whatever customization benefits it (and firefox-common.local) provide are incidental, so marking this as "notabug". Other ways of resolving the issue at hand were posted and there hasn't been any more activity about the main issue for about a week, so I'm closing this. Feel free to post any updates or request to reopen if you have more questions. [1]: https://github.com/netblue30/firejail/issues/5339#issuecomment-1227577009
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear labels   
LTS merge

   
LTS merge

   
bug

   
bug

   
converted-to-discussion

   
doc-todo

   
documentation

   
duplicate

   
enhancement

   
file-transfer

   
firecfg

   
firejail-in-firejail

   
firetools

   
graphics

   
help wanted

   
information_old

   
installation

   
invalid

   
modif

   
moved

   
needinfo

   
networking

   
notabug

   
notourbug

   
old-version

   
overlayfs

   
packaging

   
profile-request

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#2963
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?