[GH-ISSUE #2097] firecfg: allow for ignoring specific apps #1419

New issue

Closed

opened 2026-05-05 08:04:59 -06:00 by gitea-mirror · 18 comments

gitea-mirror commented 2026-05-05 08:04:59 -06:00

Owner

Copy link

Originally created by @Vincent43 on GitHub (Aug 27, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2097

Currently firecfg unconditionally creates symlinks for all apps it detects. This is problematic if user doesn't want to use specific app with firejail.

I propose allowing users to prevent creating symlinks for chosen apps: firecfg --ignore <app_name>. The database of ignored apps could be saved same way as database of allowed users is currently.

This was discussed before: https://github.com/netblue30/firejail/issues/1675

Originally created by @Vincent43 on GitHub (Aug 27, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2097 Currently firecfg unconditionally creates symlinks for all apps it detects. This is problematic if user doesn't want to use specific app with firejail. I propose allowing users to prevent creating symlinks for chosen apps: `firecfg --ignore <app_name>`. The database of ignored apps could be saved same way as database of allowed users is currently. This was discussed before: https://github.com/netblue30/firejail/issues/1675

gitea-mirror 2026-05-05 08:04:59 -06:00

• closed this issue
• added the
  enhancement
  firecfg
  labels

gitea-mirror commented 2026-05-05 08:05:03 -06:00

Author

Owner

Copy link

@chiraag-nataraj commented on GitHub (Aug 27, 2018):

How about, instead, have an -a/--all flag which would replicate the behaviour seen here and otherwise, only link the apps listed on the command-line?

<!-- gh-comment-id:416298683 --> @chiraag-nataraj commented on GitHub (Aug 27, 2018): How about, instead, have an `-a/--all` flag which would replicate the behaviour seen here and otherwise, only link the apps listed on the command-line?

gitea-mirror commented 2026-05-05 08:05:04 -06:00

Author

Owner

Copy link

@chiraag-nataraj commented on GitHub (Aug 27, 2018):

This way, you could also use --clean to clean up only specific links or --clean --all to clean all links.

<!-- gh-comment-id:416298800 --> @chiraag-nataraj commented on GitHub (Aug 27, 2018): This way, you could also use `--clean` to clean up only specific links or `--clean --all` to clean all links.

gitea-mirror commented 2026-05-05 08:05:05 -06:00

Author

Owner

Copy link

@Vincent43 commented on GitHub (Aug 27, 2018):

Ability to symlink only chosen apps would be useful too but it's something different. Usecase which I have in mind is ignoring one,two or three apps among dozens which is rather hard to type in cmdline in whitelist mode so I prefer blacklisting.

EDIT: just checked that I have over 60 firejail symlinks created with firecfg. Providing all of them in cmdline in order to exempt a few of them isn't reasonable for me.

<!-- gh-comment-id:416310924 --> @Vincent43 commented on GitHub (Aug 27, 2018): Ability to symlink only chosen apps would be useful too but it's something different. Usecase which I have in mind is ignoring one,two or three apps among dozens which is rather hard to type in cmdline in whitelist mode so I prefer blacklisting. EDIT: just checked that I have over 60 firejail symlinks created with firecfg. Providing all of them in cmdline in order to exempt a few of them isn't reasonable for me.

gitea-mirror commented 2026-05-05 08:05:05 -06:00

Author

Owner

Copy link

@chiraag-nataraj commented on GitHub (Aug 27, 2018):

So maybe have files like firecfg.allow and firecfg.deny (names up for debate)? That way, if you only want to allow specific programs, edit firecfg.allow. If you only want to deny specific programs, edit firecfg.deny. If neither of those exists, we get the existing behavior.

<!-- gh-comment-id:416327749 --> @chiraag-nataraj commented on GitHub (Aug 27, 2018): So maybe have files like `firecfg.allow` and `firecfg.deny` (names up for debate)? That way, if you only want to allow specific programs, edit `firecfg.allow`. If you only want to deny specific programs, edit `firecfg.deny`. If neither of those exists, we get the existing behavior.

gitea-mirror commented 2026-05-05 08:05:06 -06:00

Author

Owner

Copy link

@Vincent43 commented on GitHub (Aug 27, 2018):

That sounds good!

<!-- gh-comment-id:416330356 --> @Vincent43 commented on GitHub (Aug 27, 2018): That sounds good!

gitea-mirror commented 2026-05-05 08:05:07 -06:00

Author

Owner

Copy link

@hlein commented on GitHub (Nov 21, 2020):

I propose moving firecfg.config under /etc/ - /etc/firejail/firecfg.config, or whatever.

More advanced features like a .local, .deny, .allow, or whatever, are all well and good to keep discussing, but in the meantime I would argue simply: these amount to configuration files, they should go in a path that a) system administrators expect to find configs in and b) distribution packaging tools expect to store configs in, and therefore won't silently overwrite local customizations during version upgrades.

There's multiple issues regarding this - #408 which refers to #2829 which was closed with a comment pointing here.

If I make a PR that relocates firecfg.config from LIBDIR/firejail/ to SYSCONFDIR/firejail/, is it likely to be accepted?

Thanks!

<!-- gh-comment-id:731489807 --> @hlein commented on GitHub (Nov 21, 2020): I propose moving `firecfg.config` under `/etc/` - `/etc/firejail/firecfg.config`, or whatever. More advanced features like a `.local`, `.deny`, `.allow`, or whatever, are all well and good to keep discussing, but in the meantime I would argue simply: these amount to configuration files, they should go in a path that a) system administrators expect to find configs in and b) distribution packaging tools expect to store configs in, and therefore won't silently overwrite local customizations during version upgrades. There's multiple issues regarding this - #408 which refers to #2829 which was closed with a comment pointing here. If I make a PR that relocates `firecfg.config` from `LIBDIR/firejail/` to `SYSCONFDIR/firejail/`, is it likely to be accepted? Thanks!

gitea-mirror commented 2026-05-05 08:05:08 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (Nov 21, 2020):

I am strongly in favour of using /etc instead of /usr/lib64 for this and I don't think anyone is against it.

<!-- gh-comment-id:731525425 --> @rusty-snake commented on GitHub (Nov 21, 2020): I am strongly in favour of using /etc instead of /usr/lib64 for this and I don't think anyone is against it.

gitea-mirror commented 2026-05-05 08:05:08 -06:00

Author

Owner

Copy link

@hlein commented on GitHub (Nov 24, 2020):

I am strongly in favour of using /etc instead of /usr/lib64 for this and I don't think anyone is against it.

Sweet, thanks! I will work on this as soon as I get a chance.

<!-- gh-comment-id:733162469 --> @hlein commented on GitHub (Nov 24, 2020): > I am strongly in favour of using /etc instead of /usr/lib64 for this and I don't think anyone is against it. Sweet, thanks! I will work on this as soon as I get a chance.

gitea-mirror commented 2026-05-05 08:05:09 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (May 24, 2021):

Interesting workaround: https://github.com/kugland/nojail

<!-- gh-comment-id:846997549 --> @rusty-snake commented on GitHub (May 24, 2021): Interesting workaround: https://github.com/kugland/nojail

gitea-mirror commented 2026-05-05 08:05:10 -06:00

Author

Owner

Copy link

@rieje commented on GitHub (Oct 2, 2021):

Couldn't you just symlink it to the actual binary you want, i.e. /usr/bin/<app>? But I agree, an option to ignore apps so no needless symlinks are needed is ideal.

<!-- gh-comment-id:932835105 --> @rieje commented on GitHub (Oct 2, 2021): Couldn't you just symlink it to the actual binary you want, i.e. `/usr/bin/<app>`? But I agree, an option to ignore apps so no needless symlinks are needed is ideal.

gitea-mirror commented 2026-05-05 08:05:10 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (Nov 14, 2021):

firecfg.config is now located in /etc/firejail which make overwriting by users easier.

I wanted to add a note in RELNOTES about that but that got me wondering what recommendation we should give distributors

1. Replace user changes (current situation): If a user adds/removes program to/from firecfg.config an update of firejail will undo this.
   • Pro: Users get entries in firecfg.config for new programs
   • Pro: Users get entries in firecfg.config removed if the are known to break
   • Con: User added programs are (silently) now longer jailed
   • Con: User removed programs start breaking again
2. Noreplace user changes: If a user modifies firecfg.config it will not be updated on updated of firejail.
   • Pro: User modifications are still in effect
   • Con: New programs do not get jailed automatically

---

We could solve all this if we do a second relocate and implement a override mechanism.

Proposal:

• Relocate firecfg.config to LIBDIR/firecfg.config back
• Add a /etc/firejail/firecfg.config.local file like:

  # This is a comment
  !firefox        <--- skip firefox
  ffmpeg     <--- add ffmpeg
  

<!-- gh-comment-id:968308776 --> @rusty-snake commented on GitHub (Nov 14, 2021): firecfg.config is now located in `/etc/firejail` which make overwriting by users easier. I wanted to add a note in RELNOTES about that but that got me wondering what recommendation we should give distributors 1. Replace user changes (current situation): If a user adds/removes program to/from firecfg.config an update of firejail will undo this. - Pro: Users get entries in firecfg.config for new programs - Pro: Users get entries in firecfg.config removed if the are known to break - Con: User added programs are (silently) now longer jailed - Con: User removed programs start breaking again 2. Noreplace user changes: If a user modifies firecfg.config it will not be updated on updated of firejail. - Pro: User modifications are still in effect - Con: New programs do not get jailed automatically --- We could solve all this if we do a second relocate and implement a override mechanism. Proposal: - Relocate firecfg.config to `LIBDIR/firecfg.config` back - Add a /etc/firejail/firecfg.config.local file like: ``` # This is a comment !firefox <--- skip firefox ffmpeg <--- add ffmpeg ```

gitea-mirror commented 2026-05-05 08:05:10 -06:00

Author

Owner

Copy link

@hlein commented on GitHub (Nov 14, 2021):

I wanted to add a note in RELNOTES about that but that got me wondering what recommendation we should give distributors

I maintain the Gentoo package of firejail, and we have a very nice mechanism for handling changes to config files: etc-update. It knows which files being deployed/updated count as "config files", and gives a nice menu/diff/editor-based way to merge/arbitrate changes. I believe many other distros have similar mechanisms although maybe they are package-specific.

My next update to the Gentoo package was going to deploy some distro-specific changes to firecfg.config (things I know don't work well on Gentoo for whatever reason, but aren't worth disabling across the board for all firejail installs IMO). Users can also make their own local edits to firecfg.config, and etc-update will prevent stomping on their changes across upgrades.

So, I hope this won't be chosen:

• Relocate firecfg.config to LIBDIR/firecfg.config back

but this would be great:

• Add a /etc/firejail/firecfg.config.local file like:

  # This is a comment
  !firefox        <--- skip firefox
  ffmpeg     <--- add ffmpeg
  

I was going to suggest -, but ! also makes sense.

<!-- gh-comment-id:968365273 --> @hlein commented on GitHub (Nov 14, 2021): > I wanted to add a note in RELNOTES about that but that got me wondering what recommendation we should give distributors I maintain the Gentoo package of firejail, and we have a very nice mechanism for handling changes to config files: `etc-update`. It knows which files being deployed/updated count as "config files", and gives a nice menu/diff/editor-based way to merge/arbitrate changes. I believe many other distros have similar mechanisms although maybe they are package-specific. My next update to the Gentoo package was going to deploy some distro-specific changes to `firecfg.config` (things I know don't work well on Gentoo for whatever reason, but aren't worth disabling across the board for all firejail installs IMO). Users can also make their own local edits to `firecfg.config`, and etc-update will prevent stomping on their changes across upgrades. So, I hope this won't be chosen: > * Relocate firecfg.config to `LIBDIR/firecfg.config` back but this would be great: > * Add a /etc/firejail/firecfg.config.local file like: > ``` > # This is a comment > !firefox <--- skip firefox > ffmpeg <--- add ffmpeg > ``` I was going to suggest -, but ! also makes sense.

gitea-mirror commented 2026-05-05 08:05:11 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (Nov 14, 2021):

So, I hope this won't be chosen:

The two points are linked with a logical "and" so both would be done in one PR.

I maintain the Gentoo package of firejail

Great, somebody more I know to ping for packaging issues.

I believe many other distros have similar mechanisms although maybe they are package-specific.

Fedora: If a file is marked as %config, it will be saved as FILENAME.rpmsave if it has user modifications. If it is marked as %config(noreplace), it is installed as FILENAME.rpmnew. There is rpmconf and python3-dnf-plugin-rpmconf which provide such install/keep/diff/... features but they are not installed by default nor do the have an effect if you update your system via gnome-software (what I not recommend to do).

<!-- gh-comment-id:968367186 --> @rusty-snake commented on GitHub (Nov 14, 2021): > So, I hope this won't be chosen: The two points are linked with a logical "and" so both would be done in one PR. > I maintain the Gentoo package of firejail Great, somebody more I know to ping for packaging issues. > I believe many other distros have similar mechanisms although maybe they are package-specific. Fedora: If a file is marked as `%config`, it will be saved as `FILENAME.rpmsave` if it has user modifications. If it is marked as `%config(noreplace)`, it is installed as `FILENAME.rpmnew`. There is `rpmconf` and `python3-dnf-plugin-rpmconf` which provide such install/keep/diff/... features but they are not installed by default nor do the have an effect if you update your system via gnome-software (what I not recommend to do).

gitea-mirror commented 2026-05-05 08:05:12 -06:00

Author

Owner

Copy link

@hlein commented on GitHub (Nov 14, 2021):

So, I hope this won't be chosen:

The two points are linked with a logical "and" so both would be done in one PR.

But... do they need to be? If we will have a firecfg.config.local for site-local changes (and there's symmetry there for profile .local files), why not let firecfg.config live under /etc/ ? We don't put profiles under LIBDIR, after all.

I maintain the Gentoo package of firejail

Great, somebody more I know to ping for packaging issues.

Sure :)

I believe many other distros have similar mechanisms although maybe they are package-specific.

Fedora: If a file is marked as %config, it will be saved as FILENAME.rpmsave if it has user modifications. If it is marked as %config(noreplace), it is installed as FILENAME.rpmnew. There is rpmconf and python3-dnf-plugin-rpmconf which provide such install/keep/diff/... features but they are not installed by default nor do the have an effect if you update your system via gnome-software (what I not recommend to do).

That sounds sort of painful, but at least it is a thing. I mean really, software deploying default config files that users/admins can modify, and then it's the distro's problem to decide what to do upon upgrading the package, is a normal thing.

<!-- gh-comment-id:968373883 --> @hlein commented on GitHub (Nov 14, 2021): > > So, I hope this won't be chosen: > > The two points are linked with a logical "and" so both would be done in one PR. But... do they need to be? If we will have a `firecfg.config.local` for site-local changes (and there's symmetry there for profile `.local` files), why not let `firecfg.config` live under `/etc/` ? We don't put profiles under `LIBDIR`, after all. > > I maintain the Gentoo package of firejail > > Great, somebody more I know to ping for packaging issues. Sure :) > > I believe many other distros have similar mechanisms although maybe they are package-specific. > > Fedora: If a file is marked as `%config`, it will be saved as `FILENAME.rpmsave` if it has user modifications. If it is marked as `%config(noreplace)`, it is installed as `FILENAME.rpmnew`. There is `rpmconf` and `python3-dnf-plugin-rpmconf` which provide such install/keep/diff/... features but they are not installed by default nor do the have an effect if you update your system via gnome-software (what I not recommend to do). That sounds sort of painful, but at least it is a thing. I mean really, software deploying default config files that users/admins can modify, and then it's the distro's problem to decide what to do upon upgrading the package, is a normal thing.

gitea-mirror commented 2026-05-05 08:05:12 -06:00

Author

Owner

Copy link

@kmk3 commented on GitHub (Nov 15, 2021):

@hlein commented on Nov 15:

So, I hope this won't be chosen:

The two points are linked with a logical "and" so both would be done in one
PR.

But... do they need to be? If we will have a firecfg.config.local for
site-local changes (and there's symmetry there for profile .local files),
why not let firecfg.config live under /etc/ ? We don't put profiles under
LIBDIR, after all.

Considering that firecfg.config is basically just a giant list of programs
(rather than having many individual options like in firejail.config), I also
think that having a separate file for admin modifications would be better, as
it seems that conflicts would happen much more often and that the diff would be
harder to read (compared to that of firejail.config).

I believe many other distros have similar mechanisms although maybe they
are package-specific.

Fedora: If a file is marked as %config, it will be saved as
FILENAME.rpmsave if it has user modifications. If it is marked as
%config(noreplace), it is installed as FILENAME.rpmnew. There is
rpmconf and python3-dnf-plugin-rpmconf which provide such
install/keep/diff/... features but they are not installed by default nor do
the have an effect if you update your system via gnome-software (what I not
recommend to do).

That sounds sort of painful, but at least it is a thing. I mean really,
software deploying default config files that users/admins can modify, and
then it's the distro's problem to decide what to do upon upgrading the
package, is a normal thing.

Agreed.

On Arch, if you tried to install a package that would conflict with a modified
/etc/firejail/firecfg.config, pacman would just save the new version as
/etc/firejail/firecfg.config.pacnew, print a warning and then finish installing
normally. After the install, these files could be compared and merged by
running pacdiff (which would open them in vimdiff by default), if/when you
felt like doing so. Details:

• https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave

IIRC, on Debian apt asks interactively in an ncurses-based UI what to do if a
configuration conflict happens (personally, I'd much rather not have upgrades
interrupted by default just because of that, but I suppose that it could be
useful in places where any breakage at all would be a big problem).

So considering that configuration files like /etc/firejail/firejail.config have
been around for a long time without having .local versions and that at least
apt, emerge, pacman and rpm apparently support conflict resolution in /etc in
seemingly good enough ways, to me it seems that this is a pretty standard
feature of package managers.

<!-- gh-comment-id:968553372 --> @kmk3 commented on GitHub (Nov 15, 2021): @hlein commented [on Nov 15](https://github.com/netblue30/firejail/issues/2097#issuecomment-968373883): > > > So, I hope this won't be chosen: > > > > The two points are linked with a logical "and" so both would be done in one > > PR. > > But... do they need to be? If we will have a `firecfg.config.local` for > site-local changes (and there's symmetry there for profile `.local` files), > why not let `firecfg.config` live under `/etc/` ? We don't put profiles under > `LIBDIR`, after all. Considering that firecfg.config is basically just a giant list of programs (rather than having many individual options like in firejail.config), I also think that having a separate file for admin modifications would be better, as it seems that conflicts would happen much more often and that the diff would be harder to read (compared to that of firejail.config). > > > I believe many other distros have similar mechanisms although maybe they > > > are package-specific. > > > > Fedora: If a file is marked as `%config`, it will be saved as > > `FILENAME.rpmsave` if it has user modifications. If it is marked as > > `%config(noreplace)`, it is installed as `FILENAME.rpmnew`. There is > > `rpmconf` and `python3-dnf-plugin-rpmconf` which provide such > > install/keep/diff/... features but they are not installed by default nor do > > the have an effect if you update your system via gnome-software (what I not > > recommend to do). > > That sounds sort of painful, but at least it is a thing. I mean really, > software deploying default config files that users/admins can modify, and > then it's the distro's problem to decide what to do upon upgrading the > package, is a normal thing. Agreed. On Arch, if you tried to install a package that would conflict with a modified /etc/firejail/firecfg.config, pacman would just save the new version as /etc/firejail/firecfg.config.pacnew, print a warning and then finish installing normally. After the install, these files could be compared and merged by running `pacdiff` (which would open them in `vimdiff` by default), if/when you felt like doing so. Details: * <https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave> IIRC, on Debian apt asks interactively in an ncurses-based UI what to do if a configuration conflict happens (personally, I'd much rather not have upgrades interrupted by default just because of that, but I suppose that it could be useful in places where any breakage at all would be a big problem). So considering that configuration files like /etc/firejail/firejail.config have been around for a long time without having .local versions and that at least apt, emerge, pacman and rpm apparently support conflict resolution in /etc in seemingly good enough ways, to me it seems that this is a pretty standard feature of package managers.

gitea-mirror commented 2026-05-05 08:05:12 -06:00

Author

Owner

Copy link

@WhyNotHugo commented on GitHub (Jul 8, 2022):

How about /etc/firejail/firecfg.d/ which can include many files, processed in-order.

So a default 10-default.config can include the current defaults, but one can include overrides such as 20-no-mpv.config with !mpv?

The biggest problem with having to mutate a package-provided file for configuration, is that it does not allow for a second package to ship a configuration file. I can currently have a package which ships a variety of configurations by dropping in files in /etc/modprobe.d/, usr/lib/tmpfiles.d/ , etc. However, it can't provide a file that's already installed by another package.

Sure, scripts could mutate the package-provided /etc/firejail/firecfg.config, but that requires making sure it's kept aligned with new versions after each update somehow. In the end, the idea of "mutable package-provided files" is always tricky. Being able to use drop-in files would solve this (which is what happens with the *.local files now for profiles.

<!-- gh-comment-id:1179160459 --> @WhyNotHugo commented on GitHub (Jul 8, 2022): How about `/etc/firejail/firecfg.d/` which can include many files, processed in-order. So a default `10-default.config` can include the current defaults, but one can include overrides such as `20-no-mpv.config` with `!mpv`? The biggest problem with having to mutate a package-provided file for configuration, is that it does not allow for a second package to ship a configuration file. I can currently have a package which ships a variety of configurations by dropping in files in `/etc/modprobe.d/`, `usr/lib/tmpfiles.d/ `, etc. However, it can't provide a file that's already installed by another package. Sure, scripts could mutate the package-provided `/etc/firejail/firecfg.config`, but that requires making sure it's kept aligned with new versions after each update somehow. In the end, the idea of "mutable package-provided files" is always tricky. Being able to use drop-in files would solve this (which is what happens with the `*.local` files now for profiles.

gitea-mirror commented 2026-05-05 08:05:13 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (Jul 8, 2022):

That's what firecfg.py does for 1,5 or 2 years now and it works great.

https://github.com/rusty-snake/firecfg.py/tree/master/firecfgpy/groups

It also solves the privileged-programs/chrom*/file-archivers can not be sandboxed on some systems issue by making own files for the which can be enabled/disable.

<!-- gh-comment-id:1179187628 --> @rusty-snake commented on GitHub (Jul 8, 2022): That's what firecfg.py does for 1,5 or 2 years now and it works great. https://github.com/rusty-snake/firecfg.py/tree/master/firecfgpy/groups It also solves the privileged-programs/chrom\*/file-archivers can not be sandboxed on some systems issue by making own files for the which can be enabled/disable.

gitea-mirror commented 2026-05-05 08:05:13 -06:00

Author

Owner

Copy link

@kmk3 commented on GitHub (Jul 1, 2023):

PR created:

• #5876

Feel free to test and review.

<!-- gh-comment-id:1616059776 --> @kmk3 commented on GitHub (Jul 1, 2023): PR created: * #5876 Feel free to test and review.

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

Subscribe

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

No description provided.