Firecfg still creates desktop files despite being disabled in firecfg.config

[jkcdarunday]

Description

Because firejail breaks spectacle on KDE Plasma Wayland (#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

• 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
...

[nexpspace]

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.

[vendion]

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.

[kmk3]

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]

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]

Relates to:

• firecfg: allow for ignoring specific apps #2097

[rusty-snake]

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).

[vendion]

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..

[rusty-snake]

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.

[vendion]

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.

[rusty-snake]

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.

[vendion]

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]

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]

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.

[rusty-snake]

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.

[kmk3]

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