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 343896 - "gio open" should execute .desktop files instead of editing them
"gio open" should execute .desktop files instead of editing them
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2006-06-05 10:15 UTC by Kevin Kubasik
Modified: 2018-05-24 10:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
proposed patch (2.23 KB, patch)
2010-10-12 11:37 UTC, Pedro Fragoso
none Details | Review
Use gdesktopapp instead of parsing (2.75 KB, patch)
2010-10-13 16:14 UTC, Pedro Fragoso
needs-work Details | Review
execute desktop files (2.14 KB, patch)
2013-11-15 13:57 UTC, Ondrej Holy
reviewed Details | Review

Description Kevin Kubasik 2006-06-05 10:15:15 UTC
When the beagle-live handler gets a hit, it just uses the default application for that mimetype. While this is fine for most files, .desktop files are an exception, and deskbar should probably detect their extension and execute the relevant command as opposed to opening the file for editing.
Comment 1 Raphael Slinckx 2006-06-05 11:34:36 UTC
It sounds like a gnome-open (or the equivalent library call) bug. Reassigning.

Libgnome maintainer: Is it normal that "gnome-open xxx.desktop", or the equivalent library call, opens the .desktop file for editing, instead of executing it ?
Comment 2 Kjartan Maraas 2006-06-09 09:43:23 UTC
It's just opening it as a text file in gedit here which I think is the expected thing. To execute the command line given in the desktop file the code would need to parse the .desktop file I guess which is out of scope for gnome-open? 
Comment 3 Raphael Slinckx 2006-06-09 12:36:45 UTC
I don't know what nautilus does, but i think when you double click a .desktop file it launches the associated program, i guess they don't use gnome-open then..

So what i need to do in deskbar, is to sniff the mime-type for the file before gnome-open, then detect if it's a .desktop file. Then use libgnome-desktop to parse the file, and launch it, or else use gnome-open..

In my opinion this should be done in gnome-open itself, since special casing all kind of files at application level is not a very good thing.

I don't know of any case where a user would want to edit a .desktop file in gedit rather than executing the program associated with it (just like nautilus does). The developper know this and can just open it with his favorite editor ?
Comment 4 Kevin Kubasik 2006-06-09 20:33:17 UTC
I have to agree with Raphael here that this should probably be handled in gnome-open, its a pain to have to implement .desktop parsing code in every beagle front end when I can't really think of an instance where the expected behavior wouldn't be to execute the associated command.
Comment 5 Kjartan Maraas 2006-06-12 11:46:49 UTC
I agree that it's bad to have to handle this at the application level, but we have to face the fact that libgnome and libgnomeui are on their way to being deprecated. Maybe gnome-open should be moved to gnome-vfs along with this enhancement request for it?
Comment 6 Raphael Slinckx 2006-06-12 12:40:11 UTC
I'm aware that libgnome* are going to be deprecated at some point in the future. However this isn't going to happen before next cycle, or maybe 2.18, who knows ?
I'd like to have this fixed in next major release of deskbar, it could probably help other tools as well..

We can move this to gnome-vfs component, as well as gnome-open, but it's only moving the problem around ;)

In any case i'd be very grateful if gnome-open could be patched, or if someone could provide a patch for deskbar..
Comment 7 Kjartan Maraas 2006-10-23 12:58:49 UTC
I guess this should be taken up on desktop-devel-list to get a feel for what people want gnome-open to do. If there's consensus to implement this there I won't stand it anyone's way :-)
Comment 8 Peter 2006-12-24 18:44:40 UTC
seems to be a dup of bug 307172.
Comment 9 Kjartan Maraas 2007-10-01 12:15:39 UTC
And gnome-vfs executes based on MIME type and associated action. This won't fly here and thus would require us to add .desktop parsing knowledge to gnome_vfs_url_show_with_env() I guess. Do we have api to just get the exec command from the .desktop file? Or would we need to parse it ourselves?
Comment 10 ulrik sverdrup 2008-04-11 22:45:43 UTC
Gnome has a high-level API to desktop files!

http://library.gnome.org/devel/gnome-desktop/stable/gnome-desktop-GnomeDesktopItem.html

Such things are important on the desktop! We are talking modern, sane, user-desktop oriented features here, and I have exactly the same expecations as the original poster. Double-clicking a desktop file, or launching it in any standard way (like gnome-open), should launch the represented application.

Please help take Gnome to the next level where files are more than files and Gnome actually has a high level API.
Comment 11 André Klapper 2009-02-22 22:10:36 UTC
gnome-open is deprecated and has been superseded by gvfs-open.
If this is still an issue in gvfs-open, please add a comment and/or move this bug to the gvfs product.
Otherwise this report will soon be closed as OBSOLETE/WONTFIX.
Comment 12 Kjartan Maraas 2009-05-04 07:48:53 UTC
And here we go...
Comment 13 Raphael Slinckx 2009-05-04 08:11:54 UTC
It's still not working with gvfs-open :)
Comment 14 Pedro Fragoso 2010-10-12 11:37:44 UTC
Created attachment 172177 [details] [review]
proposed patch

I really didn't find a API to get the Exec and run it so i've ended up parsing the desktop.

Not sure if this is the right path but here's the patch.
Comment 15 Bastien Nocera 2010-10-12 13:39:27 UTC
(In reply to comment #14)
> Created an attachment (id=172177) [details] [review]
> proposed patch
> 
> I really didn't find a API to get the Exec and run it so i've ended up parsing
> the desktop.
> 
> Not sure if this is the right path but here's the patch.

You should use g_desktop_app_info_new_from_filename(), and then use GAppInfo's methods to launch the application. Much easier than parsing by hand :)
Comment 16 Pedro Fragoso 2010-10-13 16:14:34 UTC
Created attachment 172285 [details] [review]
Use gdesktopapp instead of parsing

Updated using g_desktop_app and denied the exec of a remote desktop.
Comment 17 Bastien Nocera 2010-10-13 16:19:03 UTC
Review of attachment 172285 [details] [review]:

::: programs/gvfs-open.c
@@ +61,3 @@
+  if (!g_file_is_native(file))
+    {
+      g_printerr (_("You cannot execute commands from a remote site\n"));

Why not? Use g_file_get_path(), and there you have a "local" filepath.

@@ +75,3 @@
+      /* is the URI of the file, the third is the error message.        */
+      g_printerr (_("%s: error opening location: %s \n"),
+		  g_get_prgname (), g_file_get_uri (file));

Why not just launch it through the "open()" call?

@@ +79,3 @@
+    }
+
+  if (g_file_is_native (file) && !is_file_uri_with_anchor (arg_string))

You already checked for g_file_is_native earlier. Why special case the "is_file_uri_with_anchor()"?
Comment 18 Rodrigo Silva 2011-07-28 03:53:25 UTC
5 years later, and gvfs-open still opens .desktop files in text editor instead of launching the corresponding app. Is this by design?
Comment 19 Jim Hill 2013-11-09 23:26:37 UTC
Please tell me I'm not going to have to apply that patch and recompile gnome myself, or write a .desktop parser complete with substitutions.

Is the seven years of silence due to some colossal stupidity on our part that everyone on the gnome team is too polite to mention?
Comment 20 Bastien Nocera 2013-11-09 23:54:41 UTC
(In reply to comment #19)
> Please tell me I'm not going to have to apply that patch and recompile gnome
> myself, 

Given that the patch still needs work, no.

> or write a .desktop parser complete with substitutions.
> 
> Is the seven years of silence due to some colossal stupidity on our part that
> everyone on the gnome team is too polite to mention?

Nobody seems to care enough about it to actually write a patch (that's applicable) to gvfs-open.

(And the fix for the original request is simple:
app = g_desktop_app_info_new_from_filename ("foo.desktop");
g_app_info_launch(app, ...);
)
Comment 21 Matthias Clasen 2013-11-11 13:06:04 UTC
There's already a gtk-launch utility which does what you need.
Comment 22 Rodrigo Silva 2013-11-11 17:50:51 UTC
(In reply to comment #21)
> There's already a gtk-launch utility which does what you need.

gtk-launch is nice, but far from enough: according https://developer.gnome.org/gtk3/stable/gtk-launch.html, it only launches .desktop files residing in /usr/share/application (btw, shouldn't it be application*s* ?).

It can't be used for launching desktop files from the $XDG_DATA_DIRS list or $XDG_DATA_HOME/applications dir, or ~/Desktop, let alone .desktop files from arbitrary paths in the filesystem.

Last but not least, even if did accept arbitrary .desktop files, clients would still have to special case them, to decide if they invoke gvfs-open or gtk-launch based on file extension, which kind of defeats the point.

IMHO, this logic should be incorporated inside gvfs-open, along with the launching itself. The .desktop parsing can be handled by Gio.

In Python this is as simple as:

from gi.repository import Gio
Gio.DesktopAppInfo.new_from_filename(filename).launch(args, None)
Comment 23 Ondrej Holy 2013-11-15 13:57:23 UTC
Created attachment 259878 [details] [review]
execute desktop files

So there is modified patch to do that. It execute desktop files, in case of error treat as non-desktop files.
Comment 24 Ross Lagerwall 2013-11-15 15:37:44 UTC
Review of attachment 259878 [details] [review]:

Apart from the minor comment, looks good.

::: programs/gvfs-open.c
@@ +107,3 @@
+	  if (info)
+	  {
+	    res = g_app_info_launch (G_APP_INFO (info), NULL, NULL, &error);

There's no point in storing error because it is never used.

@@ +116,1 @@
 	  g_clear_error (&error);

This line could then be removed
Comment 25 Matthias Clasen 2013-11-16 02:00:13 UTC
Fwiw, here is the length nautilus goes to before letting the user run a 'random' desktop file: 

https://git.gnome.org/browse/nautilus/commit/?id=7632a3e13874a2c5e8988428ca913620a25df983

Remember, this could be a file that has been downloaded from the net, and it could be running rm -rf $HOME.
Comment 26 Ondrej Holy 2013-12-05 16:58:29 UTC
You are right, there is lot of checking before however user is still allowed to run untrusted file (file outside default application dirs). I think advanced user check file before run (and don't need this warning), however oridnary user just run it in most cases, because oridnary users just simple ignores such types of warnings...

Also I think ordinary user don't use gvfs-open, so we can commit it without worrying. Similar logic is that we can't disable rm utility just only due to user can run rm -rf...

Or what do you recommend? Allow this only for desktop files in app dirs and error for others? Add e.g. "-f" option to allow execute all the desktop files? Or something else?
Comment 27 A. Walton 2013-12-05 19:32:36 UTC
(In reply to comment #26)
 
> Also I think ordinary user don't use gvfs-open, so we can commit it without
> worrying. Similar logic is that we can't disable rm utility just only due to
> user can run rm -rf...

The problem with this is that many tools shell out to gvfs-open either directly or indirectly (like comment #1, Beagle, or anything using xdg-open). Tools should not be automatically running .desktop files for exactly the reason Matthias pointed out.
Comment 28 Rodrigo Silva 2013-12-06 19:48:37 UTC
(In reply to comment #27)
> (In reply to comment #26)
> 
> > Also I think ordinary user don't use gvfs-open, so we can commit it without
> > worrying. Similar logic is that we can't disable rm utility just only due to
> > user can run rm -rf...
> 
> The problem with this is that many tools shell out to gvfs-open either directly
> or indirectly (like comment #1, Beagle, or anything using xdg-open). Tools
> should not be automatically running .desktop files for exactly the reason
> Matthias pointed out.

Would checking for the executable bit be enough for gvfs-open? It prevents running .desktop files downloaded from the net, which is a sensible concern.
Comment 29 Rodrigo Silva 2013-12-06 20:12:27 UTC
(In reply to comment #26)
> Or what do you recommend? Allow this only for desktop files in app dirs and
> error for others? Add e.g. "-f" option to allow execute all the desktop files?
> Or something else?

I think check the executable bit. If set, launch it. If not, handle as a text file (fallback to current behavior). So no errors in any case.

It's a simple check, maybe not as lengthy as what Nautilus does, but enough to prevent executing downloaded files (and torrent contents, email attachments, etc, which clients generally use xdg-open). So IMHO it's a good compromise between complex validation (which may lead to unexpected behavior) and a basic (yet effective) security measure.

(By the way, the "-f" is a good idea... for gtk-launch! To allow it to open arbitrary .desktop files outside the /usr/share/application dir)
Comment 30 Winston Weinert 2015-08-08 04:47:49 UTC
It has been 14 years since this bug was submitted, and there has been much discussion about this bug outside of this thread:

- https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/378783
- https://stackoverflow.com/questions/6020106/hashbang-for-gnome-desktop-files
- https://askubuntu.com/questions/5172/running-a-desktop-file-in-the-terminal
- https://forum.kde.org/viewtopic.php?t=37981

I think checking the executable bit is ridiculous because this appears analogous to bash checking the executable bit on a file argument. You don't see this behavior in any interpreters I am familiar with.

Why not make xdg-open *.desktop a special case and resolve the bug?
Comment 31 Ondrej Holy 2016-10-04 09:08:49 UTC
New gio cmd tool has been added in GLib and thus GVfs cmd tools has been deprecated, see Bug 769378. Please test this issue against the new gio tool and file a new bug report under GLib product (GIO component) if it is still valid.
Comment 32 Stuart Axon 2016-12-19 11:39:22 UTC
Once or twice a week I click on a desktop file expecting to launch a program and seeing a bunch of text in gedit instead.  [/rant over].

In my case it's a mix of wine programmes and commercial stuff like TurboPrint.


In one of the
xdg-mime query default application/x-desktop


@Ondrej I will definitely try the new gio tool, if it is available on my distro, Any idea of what the relevant command would be ?



In the meantime here is my fix:



1.

Install "dex" so the user can launch desktop files from the commandline.


2.
Make a desktop file to associate "application/x-desktop" to dex - put the following content into the file ~/.local/share/applications/dex.desktop

Exec=/usr/bin/dex %U
Version=1.0
Name=Launch Desktop File
GenericName=Dex
X-GNOME-FullName=Dex Desktop Launcher
Comment=Launches Other Desktop Files
Icon=myapp-icon
StartupNotify=true
Terminal=false
Type=Application
MimeType=application/x-desktop
Comment 33 Rolf Leggewie 2018-04-21 09:06:32 UTC
This is still the same with "gio open" as verified by me today on a bionic system
Comment 34 Rolf Leggewie 2018-04-21 09:08:00 UTC
I apologize, I do not know this bug tracker well enough to reassign to the proper subsystem.
Comment 35 Ondrej Holy 2018-04-23 07:53:04 UTC
Ok, let's move this in GLib/GIO though not sure what to do with it due to the concerns from Comment 25...
Comment 36 Stuart Axon 2018-04-23 09:03:59 UTC
On OSX when you first run a program it pops up a warning that says something like "this program has been downloaded from the internet... ", once you allow it to run, it can run from then in.

Nautilus could ask for confirmation on the first run of a desktop file.

The mechanism could be as simple as setting the execute bit, or something more involved, like keeping a note of the sha256 of the desktop file and some info on its target.
Comment 37 Emmanuele Bassi (:ebassi) 2018-04-23 09:22:22 UTC
(In reply to Stuart Axon from comment #36)
> On OSX when you first run a program it pops up a warning that says something
> like "this program has been downloaded from the internet... ", once you
> allow it to run, it can run from then in.
> 
> Nautilus could ask for confirmation on the first run of a desktop file.

This issue is not for Nautilus, it's for the CLI tool `gio open`. Nautilus can already deal with executable desktop files.

Additionally, GIO does not link to a GUI toolkit, unless you expect the open command to ask the user on the terminal.

> The mechanism could be as simple as setting the execute bit,

You should look at comments #28, #29, and #30.

> or something
> more involved, like keeping a note of the sha256 of the desktop file and
> some info on its target.

I don't understand what this would achieve.
Comment 38 Ondrej Holy 2018-04-23 09:25:48 UTC
(In reply to Stuart Axon from comment #36)
> Nautilus could ask for confirmation on the first run of a desktop file.

Btw I am convinced that this is exactly what nautilus does currently, but nautilus doesn't use "gio open", so this is irrelevant...
Comment 39 Emmanuele Bassi (:ebassi) 2018-04-23 09:30:47 UTC
(In reply to Ondrej Holy from comment #35)
> Ok, let's move this in GLib/GIO though not sure what to do with it due to
> the concerns from Comment 25...

Outside of presenting a prompt like:

```
The file you wish to open will launch this command:
{contents_of_exec_key}
Are you sure you wish to open it? [y/N]
```

If stdin and stdout are on a TTY.

The prompt would not really work if a GUI application decides to spawn `gio open` or `xdg-open`, instead of using the appropriate toolkit API; of we're talking about shell scripts calling `xdg-open`.

We could add heuristics like:

 - is the file inside XDG_DATA_DIRS/applications?
 - if not, is the file inside XDG_DATA_HOME/applications?
 - if not, is the file marked as executable?
 - if not, open with the text editor

Additionally, we may add the ability to remember the decision, but then we're going to need a way to store that decision somewhere.
Comment 40 Philip Withnall 2018-04-23 15:24:49 UTC
We could add an `--execute`/`-x` argument to `gio open`, which would cause it to execute `.desktop` files, and which would be a no-op on other file types. I would prefer that to a series of heuristics which wouldn’t be particularly transparent to the user.

That way, the default behaviour of `gio open blah.desktop` continues to be to safely open it in a text editor, so any scripts running that as a subprocess don’t become unsafe.
Comment 41 Stuart Axon 2018-04-23 16:59:15 UTC
I wonder who exactly this protects.   Who are the users technical enough to run a script in bash, that opens a malignant desktop file ?

The main thing I find confusing on a new computer is double clicking a desktop file for an app that I installed (usually in wine, but sometimes a native linux desktop app) and having it open in gedit.
Comment 42 Emmanuele Bassi (:ebassi) 2018-04-23 17:29:38 UTC
(In reply to Stuart Axon from comment #41)
> I wonder who exactly this protects.   Who are the users technical enough to
> run a script in bash, that opens a malignant desktop file ?

The issue is not "somebody wrote a script in bash calling `gio open` on a desktop file"; the issue is that there are applications — GUI or CLI — that spawn `xdg-open` or `gio open` internally, and may end up messing with user data if they start launching malicious desktop entry files, whereas before they didn't.

While applications using the appropriate platform API to launch applications can interpose layers of safety, we can't do the same with `gio open`.

> The main thing I find confusing on a new computer is double clicking a
> desktop file for an app that I installed (usually in wine, but sometimes a
> native linux desktop app) and having it open in gedit.

If you're "double clicking" in a file manager, I strongly recommend you file a bug against that file manager, so that it uses the appropriate API to launch an application from its desktop file; see:

 - https://developer.gnome.org/gio/stable/gio-Desktop-file-based-GAppInfo.html
 - https://developer.gnome.org/gio/stable/GAppInfo.html#g-app-info-launch
Comment 43 GNOME Infrastructure Team 2018-05-24 10:48:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/54.