firecfg does not detect all .desktop files for cleaning

[rusty-snake]

Firecfg can replace DBusActivatable=true with false in .desktop files (#1574), but does not recognize all .desktop files belonging to a programm.

OS: Fedora Workstation 29 (GNOME)
Firejail: 0.9.57

Example where it occurs:

• org.gnome.Builder.desktop gnome-builder
• org.gnome.Logs.desktop gnome-logs
• org.gnome.Maps.desktop gnome-maps
• org.gnome.Epiphany.desktop epiphany
• org.gnome.clocks.desktop gnome-clocks

Looks like no gnome- or a uppercase letter after the org.gnome. is an issue. (I don't know how firecfg scan for .desktop files).

Example where it not occurs:

• org.gnome.gedit.desktop gedit
• org.gnome.baobab.desktop baobab
• ca.desrt.dconf-editor.desktop dconf-editor
• org.gnome.Cheese.desktop cheese

Also nautilus (org.gnome.Nautilus.desktop) is cleaned up, although it does not have a firejail profile.

[rusty-snake]

IMHO a good way to fix this is that firecfg scan in all .desktop files in /usr/share/applications for the Exec line.

[glitsj16]

@rusty-snake Firecfg already does that, and it handles lower- and uppercase filenames. Also, nautilus does have a profile. I don't use firecfg but for fun I installed firejail from git master in an Arch Linux systemd-nspawn container. When running sudo firecfg --debug I can't reproduce what you're seeing. Both gedit and nautilus desktop files in ~/.local/share/applications have DBusActivatable=false. Have you tried to reproduce the issues with a more recent firejail version yet?

[SkewedZeppelin]

@glitsj16 I can reproduce the report exactly, it is indeed a problem.

I think I saw a similar issue long ago on Arch when it was first implemented, where it would ignore certain .desktops.

Even in the original implementation it was an issue #1574 (comment)

[rusty-snake]

@rusty-snake Firecfg already does that, and it handles lower- and uppercase filenames.

As I say I don't know how firecfg does that internaly (I can't C).

Also, nautilus does have a profile.

Uhh, yes, your right.

Both gedit and nautilus desktop files in ~/.local/share/applications have DBusActivatable=false.

Example where it not occurs:

Yes for baobab, nautilus and gedit it works.

Have you tried to reproduce the issues with a more recent firejail version yet?

Not yet (later I wil do this with an git version). But I can't find an commit in https://github.com/netblue30/firejail/commits/master/src/firecfg/desktop_files.c that change there something.

[glitsj16]

@rusty-snake Don't worry about it too much. @SkewedZeppelin can reproduce, so you found a bug. Nice find!

[rusty-snake]

@glitsj16 just to complete: reproduced with 8e5ad20.

[glitsj16]

@rusty-snake I can reproduce now too (originally got the working/failing examples from your OP mixed-up as you pointed out). After some more testing I can only conclude that firecfg seems pretty broken.

There's more going wrong than the DBusActivatable issue IMHO. Epiphany doesn't have that entree in its .desktop file (at least not in Arch Linux and upstream git master). Allthough firecfg reports finding /etc/firejail/epiphany.profile and creates the symlink, it doesn't create a .desktop file in ~/.local/share/applications. Furthermore, epiphany is reported to exists in /bin (which is incorrect, it's in /usr/bin) by the Configuring symlinks ... part of the firecfg run, but isn't found (or reported as such) in the Fixing desktop files ... part.

$ sudo firecfg --debug
glitsj16 0 0 0 0
Removing all firejail symlinks:

Configuring symlinks in /usr/local/bin based on firecfg.config
...
found epiphany in directory /bin
   epiphany created
...
Fixing desktop files in /home/glitsj16/.local/share/applications
checking profile for org.gnome.baobab.desktop
found /etc/firejail/baobab.profile
found baobab in directory /bin
   org.gnome.baobab.desktop created
...
checking profile for org.gnome.Epiphany.desktop
found /etc/firejail/epiphany.profile
checking profile for geoclue-where-am-i.desktop
...

The other applications you mentioned indeed fail because they don't make it thru the checks in desktop_files.c during execution of the have_profile function. Which makes sense, there are in fact no profiles with those names (Builder, clocks, Logs, Maps). That's why org.gnome-logs.desktop works, and even org.gnome.Logs.desktop when you add Logs to firecfg.config and symlink the gnome-logs.profile to Logs in /etc/firejail.

Unrelated but nonetheless problematic (at least to me as a non-firecfg user) is that sudo firecfg --clean does NOT remove the .desktop files in ~/.local/share/applications it created. What happens if an upgrade changes the Exec=foo command? Or DBusActivatable=true is added? I'm marking this as a bug. Might attract attention from firecfg devs.

[glitsj16]

@rusty-snake Just pushed a temporary fix. Lets keep this open until a proper fix is available. Thanks again for reporting!

[rusty-snake]

@glitsj16 If I read the desktop_file.c right, it doesn't search for Exec, it only checks the names.

---

Not only DBus cleaning is sometimes broken, also Exec cleaning (see #3179).

[glitsj16]

Not only DBus cleaning is sometimes broken, also Exec cleaning (see #3179).

@rusty-snake It is indeed. I'm collecting info to try to fix firecfg, but it will take a few days at least. Thanks for the input 👍 .

[rusty-snake]

@glitsj16 I have written something in python, I have to test it and will post it tomorrow.

[rusty-snake]

@glitsj16 https://gist.github.com/rusty-snake/3e4b8f8555e942d2964a181d4a5f64a0

[rusty-snake]

Quick diff

firecfg:

• total: 12
• overkill: 1 (Nautilus)
• workaround: 3 (Maps (only DBus), Logs, Builder)
• hardcoded gnome-maps fix: 0

firecfg.py:

• total: 17
• overkill: 0
• workaround: 0
• hardcoded gnome-maps fix: 1

[glitsj16]

@rusty-snake I'll have to do some more testing but your python script seems to work fine. It's too bad that firecfg bugs haven't been getting the attention they need. Hopefully this will change soon.