[GH-ISSUE #3270] name matching for .local files when .profiles include others #2053

New issue

Open

opened 2026-05-05 08:43:33 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 08:43:33 -06:00

Owner

Originally created by @jonleivent on GitHub (Mar 7, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3270

There are profiles in /etc/firejail that do little but include other profiles. This makes the creation of user .local includes somewhat difficult, as the user must read through the /etc/firejail profiles to find the one that does an include of .local, and use that name instead of the target name. It also means that users can't design .local files specific to individual named executables that share .profiles, but must instead create generic ones for all executables that share the same /etc/profile that does an include of .local. I understand the modularity reason to consolidate similar profiles, but this is the side effect.

I hit this recently with the brave browser. I created a ~/.config/firejail/brave-browser.local file, and eventually noticed that it was not included when brave was launched from a menu. On calling brave-browser from the cli, I could see that brave-browser.profile was loading brave.profile, and on inspection of those realized I needed a brave.local file instead of brave-browser.local.

My suggestion is that for .local files, their include should be done by firejail itself instead of relying on an explicit include line in a profile - and that the name of the .local file is chosen the same way that firejail chooses .profiles.

An alternative is to have a macro so that profiles can do something like:
include %NAME.local
where %NAME would expand to the top-level profile name.

Originally created by @jonleivent on GitHub (Mar 7, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3270 There are profiles in /etc/firejail that do little but include other profiles. This makes the creation of user .local includes somewhat difficult, as the user must read through the /etc/firejail profiles to find the one that does an include of .local, and use that name instead of the target name. It also means that users can't design .local files specific to individual named executables that share .profiles, but must instead create generic ones for all executables that share the same /etc/profile that does an include of .local. I understand the modularity reason to consolidate similar profiles, but this is the side effect. I hit this recently with the brave browser. I created a ~/.config/firejail/brave-browser.local file, and eventually noticed that it was not included when brave was launched from a menu. On calling brave-browser from the cli, I could see that brave-browser.profile was loading brave.profile, and on inspection of those realized I needed a brave.local file instead of brave-browser.local. My suggestion is that for .local files, their include should be done by firejail itself instead of relying on an explicit include line in a profile - and that the name of the .local file is chosen the same way that firejail chooses .profiles. An alternative is to have a macro so that profiles can do something like: `include %NAME.local` where %NAME would expand to the top-level profile name.

gitea-mirror added the

enhancement

label 2026-05-05 08:43:33 -06:00

gitea-mirror commented

2026-05-05 08:43:35 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 14, 2020):

If we do this in firejail it self we could also implement --no-locals and --no-globals which would be nice options for debugging.

@rusty-snake commented on GitHub (Mar 14, 2020): If we do this in firejail it self we could also implement `--no-locals` and `--no-globals` which would be nice options for debugging.

gitea-mirror commented

2026-05-05 08:43:36 -06:00

Author

Owner

@jonleivent commented on GitHub (Mar 14, 2020):

Somewhat related:

I don't know how common it is to try to combine multiple applications in the same firejail sandbox as I am trying (one reason I did that experiment with dbus), but if it is common, then having profiles for applications split up in terms of their whitelisting components vs. their blacklisting components (both file management and capabilities) would be useful. This is because, to run 2 or more apps in the same sandbox, their whitelists must be unioned together. Depending on the purpose for the sandbox, their blacklists may need to be unioned or intersected, or something in between. So having a clear description of the overall whitelist for each app as as distinct profile devoid of blacklist features would be a benefit.

@jonleivent commented on GitHub (Mar 14, 2020): Somewhat related: I don't know how common it is to try to combine multiple applications in the same firejail sandbox as I am trying (one reason I did that experiment with dbus), but if it is common, then having profiles for applications split up in terms of their whitelisting components vs. their blacklisting components (both file management and capabilities) would be useful. This is because, to run 2 or more apps in the same sandbox, their whitelists must be unioned together. Depending on the purpose for the sandbox, their blacklists may need to be unioned or intersected, or something in between. So having a clear description of the overall whitelist for each app as as distinct profile devoid of blacklist features would be a benefit.

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#2053

No description provided.

Rows
Columns