[GH-ISSUE #5245] Firecfg still creates desktop files despite being disabled in firecfg.config

gitea-mirror commented

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

Owner

Originally created by @jkcdarunday on GitHub (Jul 12, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5245

Description

Because firejail breaks spectacle on KDE Plasma Wayland (https://github.com/netblue30/firejail/issues/5127), I want to disable firejail for spectacle. I did this by editing /etc/firejail/firecfg.config and commenting out spectacle. And then I deleted the /usr/local/bin/spectacle symlink and the ~/.local/share/applications/org.kde.spectacle.desktop file. However, running sudo firecfg keeps on reproducing the said desktop file (but not the symlink) and the desktop file seems to cause spectacle to break because it messes up with the KDE permissions specified in the file.

Steps to Reproduce

Make sure that you are in a clean environment (delete desktop files and symlinks for spectacle)
Comment out spectacle in /etc/firejail/firecfg.config
Run sudo firecfg
Check if ~/.local/share/applications/org.kde.spectacle.desktop exists

Expected behavior

Firecfg should not produce application desktop files in the home directory when an application is commented out in firecfg.config.

Actual behavior

Firecfg creates a desktop file (but not /usr/local/bin symlinks)

Behavior without a profile

Completely deleting the profile makes it not produce a desktop file but my package manager would simply reinstall the profile by the next update so this doesn't work well as a solution.

Additional context

Environment

Archlinux
firejail version 0.9.70
KDE Plasma 5.25.2

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)

Log

Relevant output of firecfg --debug

...
checking profile for org.kde.spectacle.desktop
found /etc/firejail/spectacle.profile
found spectacle in directory /bin
   org.kde.spectacle.desktop created
...

Originally created by @jkcdarunday on GitHub (Jul 12, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5245  ### Description Because firejail breaks spectacle on KDE Plasma Wayland (https://github.com/netblue30/firejail/issues/5127), I want to disable firejail for spectacle. I did this by editing /etc/firejail/firecfg.config and commenting out spectacle. And then I deleted the /usr/local/bin/spectacle symlink and the ~/.local/share/applications/org.kde.spectacle.desktop file. However, running sudo firecfg keeps on reproducing the said desktop file (but not the symlink) and the desktop file seems to cause spectacle to break because it messes up with the KDE permissions specified in the file. ### Steps to Reproduce 1. Make sure that you are in a clean environment (delete desktop files and symlinks for spectacle) 2. Comment out spectacle in /etc/firejail/firecfg.config 3. Run sudo firecfg 4. Check if ~/.local/share/applications/org.kde.spectacle.desktop exists ### Expected behavior Firecfg should not produce application desktop files in the home directory when an application is commented out in firecfg.config. ### Actual behavior Firecfg creates a desktop file (but not /usr/local/bin symlinks) ### Behavior without a profile Completely deleting the profile makes it not produce a desktop file but my package manager would simply reinstall the profile by the next update so this doesn't work well as a solution. ### Additional context ### Environment - Archlinux - firejail version 0.9.70 - KDE Plasma 5.25.2 ### 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). - [ ] 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) ### Log Relevant output of firecfg --debug ``` ... checking profile for org.kde.spectacle.desktop found /etc/firejail/spectacle.profile found spectacle in directory /bin org.kde.spectacle.desktop created ... ```

gitea-mirror

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

closed this issue
added the
enhancement

firecfg
labels

gitea-mirror commented

2026-05-05 09:35:46 -06:00

Author

Owner

@nexpspace commented on GitHub (Oct 20, 2022):

Same problem for me on Gentoo Linux, firejail 0.9.30, KDE Plasma 5.26.1. I have to manually remove the desktop file every update (which automatically runs firecfg for me). While I would consider making spectacle work in Wayland would be an enhancement, I would consider creating desktop files for disabled applications a bug.

@nexpspace commented on GitHub (Oct 20, 2022): Same problem for me on Gentoo Linux, firejail 0.9.30, KDE Plasma 5.26.1. I have to manually remove the desktop file every update (which automatically runs `firecfg` for me). While I would consider making spectacle work in Wayland would be an enhancement, I would consider creating desktop files for disabled applications a bug.

gitea-mirror commented

2026-05-05 09:35:47 -06:00

Author

Owner

@vendion commented on GitHub (Jan 13, 2023):

This still is happening with firejail version 0.9.72 (installed as 0.9.72rc1.r8964.ee89a263e-1 from the AUR) and KDE Plasma 5.26.5. I would also agree with above that this is more of a bug than an enhancement.

@vendion commented on GitHub (Jan 13, 2023): This still is happening with firejail version 0.9.72 (installed as 0.9.72rc1.r8964.ee89a263e-1 from the AUR) and KDE Plasma 5.26.5. I would also agree with above that this is more of a bug than an enhancement.

gitea-mirror commented

2026-05-05 09:35:48 -06:00

Author

Owner

@kmk3 commented on GitHub (Jan 13, 2023):

As a workaround, do the affected applications work if creating empty profile
overrides? Example:

touch ~/.config/firejail/spectacle.profile

If not, there is also noprofile.profile, which tries to make the sandbox as
permissive as possible (for debugging purposes).

Does it work if including noprofile.profile? Example:

~/.config/firejail/spectacle.profile:

# HACK: See https://github.com/netblue30/firejail/issues/5245
include noprofile.profile

@kmk3 commented on GitHub (Jan 13, 2023): As a workaround, do the affected applications work if creating empty profile overrides? Example: ```sh touch ~/.config/firejail/spectacle.profile ``` If not, there is also noprofile.profile, which tries to make the sandbox as permissive as possible (for debugging purposes). Does it work if including noprofile.profile? Example: ~/.config/firejail/spectacle.profile: ``` # HACK: See https://github.com/netblue30/firejail/issues/5245 include noprofile.profile ```

gitea-mirror commented

2026-05-05 09:35:49 -06:00

Author

Owner

@kmk3 commented on GitHub (Jan 13, 2023):

I would also agree with above that this is more of a bug than an enhancement.

It looks like a bug to me.

@rusty-snake Thoughts?

@kmk3 commented on GitHub (Jan 13, 2023): > I would also agree with above that this is more of a bug than an enhancement. It looks like a bug to me. @rusty-snake Thoughts?

gitea-mirror commented

2026-05-05 09:35:50 -06:00

Author

Owner

@kmk3 commented on GitHub (Jan 13, 2023):

Relates to:

#2097

@kmk3 commented on GitHub (Jan 13, 2023): Relates to: * #2097

gitea-mirror commented

2026-05-05 09:35:52 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 13, 2023):

I would also agree with above that this is more of a bug than an enhancement.

It looks like a bug to me.

@rusty-snake Thoughts?

I understand that this may look like a bug from a external point of view. However to me it looks more like a new feature.

sudo firecfg does a few independent tasks like adding the current user to firejail.users, creating symlinks and "fixing" desktop files. The feature which creates the symlinks is documented and coded to create symlinks for all programs in firecfg.config (and ~/.config/firejail/(*).profile undocumented). The "fixing" desktop files feature fixes desktop files whose name (*).desktop or *\.(*).desktop have a profile in /etc/firejail or ~/.config/firejail. So two independent features have two independent sources which happen to have a huge overlap.

Of course is this confusing and can be designed better. But as everything works as deigned and just the desing is bad, it is rather a enhancement for the design than a fix for the design/implementation because a fix corrects something while a enhancements does it better (or sometimes other/in a new way, the term "better" can be subjective).

@rusty-snake commented on GitHub (Jan 13, 2023): > > I would also agree with above that this is more of a bug than an enhancement. > > It looks like a bug to me. > > @rusty-snake Thoughts? I understand that this may look like a bug from a external point of view. However to me it looks more like a new feature. `sudo firecfg` does a few independent tasks like adding the current user to `firejail.users`, creating symlinks and "fixing" desktop files. The feature which creates the symlinks is documented and coded to create symlinks for all programs in `firecfg.config` (and `~/.config/firejail/(*).profile` undocumented). The "fixing" desktop files feature fixes desktop files whose name `(*).desktop` or `*\.(*).desktop` have a profile in `/etc/firejail` or `~/.config/firejail`. So two independent features have two independent sources which happen to have a huge overlap. Of course is this confusing and can be designed better. But as everything works as deigned and just the desing is bad, it is rather a enhancement for the design than a fix for the design/implementation because a fix corrects something while a enhancements does it better (or sometimes other/in a new way, the term "better" can be subjective).

gitea-mirror commented

2026-05-05 09:35:53 -06:00

Author

Owner

@vendion commented on GitHub (Jan 15, 2023):

As a workaround, do the affected applications work if creating empty profile overrides? Example:
touch ~/.config/firejail/spectacle.profile
If not, there is also noprofile.profile, which tries to make the sandbox as permissive as possible (for debugging purposes).

Does it work if including noprofile.profile? Example:

~/.config/firejail/spectacle.profile:
# HACK: See https://github.com/netblue30/firejail/issues/5245
include noprofile.profile

There is a new commit for firejail-git in the AUR so I went ahead and tried the first suggestion of creating an empty ~/.config/firejail/spectacle.profile and making sure that ~/.local/share/applications/org.kde.spectacle.desktop didn't exist before upgrading. The result I experienced was that after the upgrade was done and the symlinks gets recreated, so does ~/.local/share/applications/org.kde.spectacle.desktop.

I'll test the other work around later to see if that changes anything..

@vendion commented on GitHub (Jan 15, 2023): > As a workaround, do the affected applications work if creating empty profile overrides? Example: > > ```shell > touch ~/.config/firejail/spectacle.profile > ``` > > If not, there is also noprofile.profile, which tries to make the sandbox as permissive as possible (for debugging purposes). > > Does it work if including noprofile.profile? Example: > > ~/.config/firejail/spectacle.profile: > > ``` > # HACK: See https://github.com/netblue30/firejail/issues/5245 > include noprofile.profile > ``` There is a new commit for firejail-git in the AUR so I went ahead and tried the first suggestion of creating an empty _~/.config/firejail/spectacle.profile_ and making sure that _~/.local/share/applications/org.kde.spectacle.desktop_ didn't exist before upgrading. The result I experienced was that after the upgrade was done and the symlinks gets recreated, so does _~/.local/share/applications/org.kde.spectacle.desktop_. I'll test the other work around later to see if that changes anything..

gitea-mirror commented

2026-05-05 09:35:53 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 15, 2023):

This should stop firecfg from doing any user related action (fixing desktop files and adding the user to firejail.users) because it can not get the user who started it:

sudo env -u SUDO_USER firecfg

I did not tested it because I don't use firecfg.

@rusty-snake commented on GitHub (Jan 15, 2023): This should stop firecfg from doing any user related action (fixing desktop files and adding the user to firejail.users) because it can not get the user who started it: ``` sudo env -u SUDO_USER firecfg ``` I did not tested it because I don't use firecfg.

gitea-mirror commented

2026-05-05 09:35:53 -06:00

Author

Owner

@vendion commented on GitHub (Jan 15, 2023):

As a workaround, do the affected applications work if creating empty profile overrides? Example:
touch ~/.config/firejail/spectacle.profile
If not, there is also noprofile.profile, which tries to make the sandbox as permissive as possible (for debugging purposes).
Does it work if including noprofile.profile? Example:
~/.config/firejail/spectacle.profile:
# HACK: See https://github.com/netblue30/firejail/issues/5245
include noprofile.profile
There is a new commit for firejail-git in the AUR so I went ahead and tried the first suggestion of creating an empty ~/.config/firejail/spectacle.profile and making sure that ~/.local/share/applications/org.kde.spectacle.desktop didn't exist before upgrading. The result I experienced was that after the upgrade was done and the symlinks gets recreated, so does ~/.local/share/applications/org.kde.spectacle.desktop.

I'll test the other work around later to see if that changes anything..

Okay, even adding include noprofile.profile to .config/firejail/spectacle.profile doesn't work.

@vendion commented on GitHub (Jan 15, 2023): > > As a workaround, do the affected applications work if creating empty profile overrides? Example: > > ```shell > > touch ~/.config/firejail/spectacle.profile > > ``` > > > > > > > > > > > > > > > > > > > > > > > > If not, there is also noprofile.profile, which tries to make the sandbox as permissive as possible (for debugging purposes). > > Does it work if including noprofile.profile? Example: > > ~/.config/firejail/spectacle.profile: > > ``` > > # HACK: See https://github.com/netblue30/firejail/issues/5245 > > include noprofile.profile > > ``` > > There is a new commit for firejail-git in the AUR so I went ahead and tried the first suggestion of creating an empty _~/.config/firejail/spectacle.profile_ and making sure that _~/.local/share/applications/org.kde.spectacle.desktop_ didn't exist before upgrading. The result I experienced was that after the upgrade was done and the symlinks gets recreated, so does _~/.local/share/applications/org.kde.spectacle.desktop_. > > I'll test the other work around later to see if that changes anything.. Okay, even adding `include noprofile.profile` to _.config/firejail/spectacle.profile_ doesn't work.

gitea-mirror commented

2026-05-05 09:35:54 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 15, 2023):

So spectacle is just incompatible with firejail. Should we remove the profile? At least for 0.9.72, it would hotfix this issue in the most common spot and since spectacle can not be sandboxed there is no lose.

@rusty-snake commented on GitHub (Jan 15, 2023): So spectacle is just incompatible with firejail. Should we remove the profile? At least for 0.9.72, it would hotfix this issue in the most common spot and since spectacle can not be sandboxed there is no lose.

gitea-mirror commented

2026-05-05 09:35:54 -06:00

Author

Owner

@vendion commented on GitHub (Jan 15, 2023):

This should stop firecfg from doing any user related action (fixing desktop files and adding the user to firejail.users) because it can not get the user who started it:
sudo env -u SUDO_USER firecfg
I did not tested it because I don't use firecfg.

I can't speak for the others in this thread, but personally, stopping firecfg from managing symlinks and fixings the desktop files is not exactly what I want to do.

While I can't speak for nexpspace as he is on Gentoo, but OP and myself we might be able to write a simple pacman hook that always runs to remove $HOME/.local/share/applications/spectacle.desktop until this issue gets resolved. Although even that has its own problems as I don't know if we can set the new hook to fire after the firecfg hook...

@vendion commented on GitHub (Jan 15, 2023): > This should stop firecfg from doing any user related action (fixing desktop files and adding the user to firejail.users) because it can not get the user who started it: > > ``` > sudo env -u SUDO_USER firecfg > ``` > > I did not tested it because I don't use firecfg. I can't speak for the others in this thread, but personally, stopping firecfg from managing symlinks and fixings the desktop files is not exactly what I want to do. While I can't speak for nexpspace as he is on Gentoo, but OP and myself we might be able to write a simple pacman hook that always runs to remove _$HOME/.local/share/applications/spectacle.desktop_ until this issue gets resolved. Although even that has its own problems as I don't know if we can set the new hook to fire after the firecfg hook...

gitea-mirror commented

2026-05-05 09:35:55 -06:00

Author

Owner

@vendion commented on GitHub (Jan 15, 2023):

So spectacle is just incompatible with firejail. Should we remove the profile? At least for 0.9.72, it would hotfix this issue in the most common spot and since spectacle can not be sandboxed there is no lose.

Under X11 it runs fine with firejail, the issue is when using Wayland something about the profile causes it to break (See #5127 which was already closed but no proper resolution it seems)

@vendion commented on GitHub (Jan 15, 2023): > So spectacle is just incompatible with firejail. Should we remove the profile? At least for 0.9.72, it would hotfix this issue in the most common spot and since spectacle can not be sandboxed there is no lose. Under X11 it runs fine with firejail, the issue is when using Wayland something about the profile causes it to break (See #5127 which was already closed but no proper resolution it seems)

gitea-mirror commented

2026-05-05 09:35:55 -06:00

Author

Owner

@vendion commented on GitHub (Jan 15, 2023):

If it could help I would be more than happy to dump out debug info, but didn't think it was needed since the ticket here originally about commenting out an application in /etc/firejail/firecfg.config doesn't prevent the fixing of desktop files step.

@vendion commented on GitHub (Jan 15, 2023): If it could help I would be more than happy to dump out debug info, but didn't think it was needed since the ticket here originally about commenting out an application in _/etc/firejail/firecfg.config_ doesn't prevent the fixing of desktop files step.

gitea-mirror commented

2026-05-05 09:35:55 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 15, 2023):

stopping firecfg from managing symlinks and fixings the desktop files is not exactly what I want to do.

It will still create symlinks.

If it could help I would be more than happy to dump out debug info,

You mean for spectacle. Yes a separate issue is better or I can just reopen #5127 if there are users who can test stuff.

@rusty-snake commented on GitHub (Jan 15, 2023): > stopping firecfg from managing symlinks and fixings the desktop files is not exactly what I want to do. It will still create symlinks. > If it could help I would be more than happy to dump out debug info, You mean for spectacle. Yes a separate issue is better or I can just reopen #5127 if there are users who can test stuff.

gitea-mirror commented

2026-05-05 09:35:56 -06:00

Author

Owner

@kmk3 commented on GitHub (Jan 11, 2024):

Does spectacle get ignored when installing firejail from #6153 and adding the
following to /etc/firejail/firecfg.d/foo.conf?

!spectacle

If not, what about the following?

!org.kde.spectacle

@kmk3 commented on GitHub (Jan 11, 2024): Does spectacle get ignored when installing firejail from #6153 and adding the following to /etc/firejail/firecfg.d/foo.conf? ``` !spectacle ``` If not, what about the following? ``` !org.kde.spectacle ```

Rows
Columns

[GH-ISSUE #5245] Firecfg still creates desktop files despite being disabled in firecfg.config #2932

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist

Log