github-starred/firejail

Fork 0

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

[GH-ISSUE #2829] Local option for firecfg.config #1769

New issue

Closed

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

gitea-mirror commented

2026-05-05 08:26:26 -06:00

Owner

Originally created by @Edu4rdSHL on GitHub (Jul 4, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2829

Actually firejail handle what profiles create using the firecfg utility reading the /usr/lib/firejail/firecfg.config file. For some reasons users will not want to sandbox some program because of functionality or another reason.

Actually you can just comment out the line of the program name that you don't want to generate and ran firefcg again. The problem is that the /usr/lib/firejail/firecfg.config overwrite in every new firejail installation. We can backup that file in the distro package manager but isn't a good idea since that additional profiles are added and more.

Will be good if we can have a /usr/lib/firejail/firecfg.local file that works in the same way that $profile.local and then you can make something like:

# Local file configuration for firecfg.config
[exclude] # It will exclude the program when generating the symlinks using firecfg
program1
program2
programN
[/exclude]

[include] # It will include the program when generating the symlinks using firecfg
program1
program2
programN
[/include]

Or well:

# Local file configuration for firecfg.config

# It will exclude the program when generating the symlinks using firecfg
exclude program1
exclude program2
exclude programN

# It will include the program when generating the symlinks using firecfg
include program1
include program2
include programN

Or is already a functionality in firejail for doing that?

Originally created by @Edu4rdSHL on GitHub (Jul 4, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2829 Actually firejail handle what profiles create using the firecfg utility reading the /usr/lib/firejail/firecfg.config file. For some reasons users will not want to sandbox some program because of functionality or another reason. Actually you can just comment out the line of the program name that you don't want to generate and ran firefcg again. The problem is that the /usr/lib/firejail/firecfg.config overwrite in every new firejail installation. We can backup that file in the distro package manager but isn't a good idea since that additional profiles are added and more. Will be good if we can have a /usr/lib/firejail/firecfg.local file that works in the same way that $profile.local and then you can make something like: ``` # Local file configuration for firecfg.config [exclude] # It will exclude the program when generating the symlinks using firecfg program1 program2 programN [/exclude] [include] # It will include the program when generating the symlinks using firecfg program1 program2 programN [/include] ``` Or well: ``` # Local file configuration for firecfg.config # It will exclude the program when generating the symlinks using firecfg exclude program1 exclude program2 exclude programN # It will include the program when generating the symlinks using firecfg include program1 include program2 include programN ``` Or is already a functionality in firejail for doing that?

gitea-mirror

2026-05-05 08:26:26 -06:00

closed this issue
added the
duplicate
label

gitea-mirror commented

2026-05-05 08:26:28 -06:00

Author

Owner

@FOSSONLY commented on GitHub (Jul 4, 2019):

Why not:

chattr -i /usr/lib/firejail/firejail.config ? ;)

On the other side, your suggestion would be more comfortable. But don't forget: Yes sandboxing has sometimes a few downsides, but sandbox nearly every program by default is the best possible way of protection. Personally I would write custom rules to some profiles, to circumvent problems.

Nick

@FOSSONLY commented on GitHub (Jul 4, 2019): Why not: chattr -i /usr/lib/firejail/firejail.config ? ;) On the other side, your suggestion would be more comfortable. But don't forget: Yes sandboxing has sometimes a few downsides, but sandbox nearly every program by default is the best possible way of protection. Personally I would write custom rules to some profiles, to circumvent problems. Nick

gitea-mirror commented

2026-05-05 08:26:29 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jul 4, 2019):

This is duplicate of https://github.com/netblue30/firejail/issues/2097 , please continue discussion there.

I believe the best solution is to treat firecfg.config as user editable file similarly to firejail.config: https://github.com/netblue30/firejail/issues/408

@Vincent43 commented on GitHub (Jul 4, 2019): This is duplicate of https://github.com/netblue30/firejail/issues/2097 , please continue discussion there. I believe the best solution is to treat `firecfg.config` as user editable file similarly to `firejail.config`: https://github.com/netblue30/firejail/issues/408

gitea-mirror commented

2026-05-05 08:26:29 -06:00

Author

Owner

@Edu4rdSHL commented on GitHub (Jul 4, 2019):

I doesn't see why it's a duplicate, are two different things... I doesn't want it "to be editable by the user" and it isn't the best solution anyways because we are missing the new added profiles. I want a .local option to preserve local changes/configuration maintaining the benefit of the new added profiles.

As note, installing firecfg.config in a place of the user home just will break firejail for packaging. We can use a .local option in $HOME/.local/lib/firejail/firecfg.local and it will be a better solution.

@Edu4rdSHL commented on GitHub (Jul 4, 2019): I doesn't see why it's a duplicate, are two different things... I doesn't want it "to be editable by the user" and it isn't the best solution anyways because we are missing the new added profiles. I want a .local option to preserve local changes/configuration maintaining the benefit of the new added profiles. As note, installing firecfg.config in a place of the user home just will break firejail for packaging. We can use a .local option in $HOME/.local/lib/firejail/firecfg.local and it will be a better solution.

gitea-mirror commented

2026-05-05 08:26:30 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 4, 2019):

@Edu4rdSHL #408 is about storing it in /etc/firejail and not under $HOME. @Vincent43 say it's a duplcate of #2097. #2097 is about ignoring some entrys in firecfg.config and adding some other (firecfg.allow, firecfg.deny, ...)

PS: you can allways create manualy a symlink sudo ln -s /usr/bin/firejail /usr/local/bin/PROGRAM

@rusty-snake commented on GitHub (Jul 4, 2019): @Edu4rdSHL #408 is about storing it in `/etc/firejail` and not under $HOME. @Vincent43 say it's a duplcate of #2097. #2097 is about ignoring some entrys in firecfg.config and adding some other (firecfg.allow, firecfg.deny, ...) PS: you can allways create manualy a symlink `sudo ln -s /usr/bin/firejail /usr/local/bin/PROGRAM`

gitea-mirror commented

2026-05-05 08:26:30 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jul 5, 2019):

@Edu4rdSHL It's duplicate because it points to the same problem. What's the best solution for it is debatable - please add your propositions in mentioned ticket. It doesn't make sense to keep every proposed solution in separate ticket because it make all discussions fragmented and in the end only one idea will be implemented.

I disagree with your stance about firecfg.local which is similar to how we handle profiles. firecfg.config is more comparable with firejail.config and we don't have firejail.local there. firejail.config is marked for backup in distro packages and users are already familiar with need to track changes in it from time to time. IMO treating firecfg.config in the same way would be consistent.

@Vincent43 commented on GitHub (Jul 5, 2019): @Edu4rdSHL It's duplicate because it points to the same problem. What's the best solution for it is debatable - please add your propositions in mentioned ticket. It doesn't make sense to keep every proposed solution in separate ticket because it make all discussions fragmented and in the end only one idea will be implemented. I disagree with your stance about `firecfg.local` which is similar to how we handle profiles. `firecfg.config` is more comparable with `firejail.config` and we don't have `firejail.local` there. `firejail.config` is marked for backup in distro packages and users are already familiar with need to track changes in it from time to time. IMO treating `firecfg.config` in the same way would be consistent.

gitea-mirror referenced this issue

2026-05-05 09:22:07 -06:00

[GH-ISSUE #4565] Block audio input in default.profile (like with video input) #2709

gitea-mirror referenced this issue

2026-05-05 09:22:09 -06:00

[GH-ISSUE #4565] Block audio input in default.profile (like with video input) #2709