Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
5 of 7 tasks
jkcdarunday opened this issue Jul 12, 2022 · 15 comments · Fixed by #6153
Closed
5 of 7 tasks

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

jkcdarunday opened this issue Jul 12, 2022 · 15 comments · Fixed by #6153
Labels
enhancement New feature request firecfg Anything related to firecfg and not firejail itself

Comments

@jkcdarunday
Copy link

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
...
@rusty-snake rusty-snake added firecfg Anything related to firecfg and not firejail itself enhancement New feature request labels Jul 12, 2022
@nexpspace
Copy link

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
Copy link

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

@kmk3
Copy link
Collaborator

kmk3 commented 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
Copy link
Collaborator

kmk3 commented 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
Copy link
Collaborator

kmk3 commented Jan 13, 2023

@rusty-snake
Copy link
Collaborator

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
Copy link

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

@rusty-snake
Copy link
Collaborator

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
Copy link

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

@rusty-snake
Copy link
Collaborator

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
Copy link

vendion commented 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
Copy link

vendion commented 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
Copy link

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

@rusty-snake
Copy link
Collaborator

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
Copy link
Collaborator

kmk3 commented 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 added a commit that referenced this issue Jan 20, 2024
@github-project-automation github-project-automation bot moved this to Done (on RELNOTES) in Release 0.9.74 Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request firecfg Anything related to firecfg and not firejail itself
Projects
Status: Done (on RELNOTES)
Development

Successfully merging a pull request may close this issue.

5 participants