After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781596 - apps-menu: DnD to Desktop doesn't set executable bit [3.24.1]
apps-menu: DnD to Desktop doesn't set executable bit [3.24.1]
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: extensions
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-04-21 20:17 UTC by Jeremy Bicha
Modified: 2017-04-24 15:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
apps-menu: Mark copied .desktop files as trusted (2.38 KB, patch)
2017-04-21 23:02 UTC, Florian Müllner
committed Details | Review
apps-menu: 'Touch' copied .desktop file after updating attributes (2.31 KB, patch)
2017-04-21 23:02 UTC, Florian Müllner
committed Details | Review

Description Jeremy Bicha 2017-04-21 20:17:14 UTC
Ubuntu GNOME 17.04

I built gnome-shell-extensions 3.24.1 and tried out the new feature where you can drag and drop an Applications launcher from the Applications menu to the Desktop if you have Desktop Icons turned on.

The feature doesn't work in Ubuntu because the newly created file does not have the executable bit set. I think the failure is because of a patch in Ubuntu that was not accepted into GNOME.

https://wiki.ubuntu.com/SecurityTeam/Policies#Execute-Permission_Bit_Required
https://bazaar.launchpad.net/~ubuntu-desktop/nautilus/ubuntu/view/head:/debian/patches/06_never_exec_nonexec_launchers.patch

Without the executable bit, the file does not show the app icon and shows as a text file named org.gnome.Calculator.desktop (for instance).

Therefore, it does not make sense for me to push this package through Ubuntu's Stable Release Updates process if the new feature in a "bugfix" release doesn't work.
Comment 1 Florian Müllner 2017-04-21 23:02:14 UTC
Created attachment 350214 [details] [review]
apps-menu: Mark copied .desktop files as trusted

The application can already be launched from the menu without further
confirmation from the user, so there is no security gain in asking the
user to trust it when launched from the desktop - just set the appropriate
attributes of the newly copied file to mark it as trusted to nautilus.
Comment 2 Florian Müllner 2017-04-21 23:02:19 UTC
Created attachment 350215 [details] [review]
apps-menu: 'Touch' copied .desktop file after updating attributes

At least for now, nautilus' file monitor is blind to certain metadata
updates:
https://git.gnome.org/browse/nautilus/tree/src/nautilus-mime-actions.c#n1537

So in order for the changes in the previous patch to take effect
immediately, we need to force nautilus to reload the file info.
Achieve this by updating the access time of the newly copied file
after marking it as trusted.
Comment 3 Jeremy Bicha 2017-04-21 23:22:03 UTC
Thanks for the quick fix! I tested with these 2 patches and my test case works now.
Comment 4 Rui Matos 2017-04-24 14:48:59 UTC
Review of attachment 350214 [details] [review]:

who consumes the metadata::trusted attribute?

logic seems fine
Comment 5 Rui Matos 2017-04-24 14:52:04 UTC
Review of attachment 350215 [details] [review]:

ok
Comment 6 Florian Müllner 2017-04-24 15:21:44 UTC
(In reply to Rui Matos from comment #4)
> who consumes the metadata::trusted attribute?

Nautilus:
https://git.gnome.org/browse/nautilus/tree/src/nautilus-directory-async.c#n3591
Comment 7 Florian Müllner 2017-04-24 15:24:08 UTC
Attachment 350214 [details] pushed as 5cb2657 - apps-menu: Mark copied .desktop files as trusted
Attachment 350215 [details] pushed as 8453cf0 - apps-menu: 'Touch' copied .desktop file after updating attributes