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 ?

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? 

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 ?

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.

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?

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

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

seems to be a dup of bug 307172.

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?

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.

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.

And here we go...

It's still not working with gvfs-open :)

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.

(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 :)

Created attachment 172285 [details] [review]
Use gdesktopapp instead of parsing

Updated using g_desktop_app and denied the exec of a remote desktop.

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()"?

5 years later, and gvfs-open still opens .desktop files in text editor instead of launching the corresponding app. Is this by design?

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?

(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, ...);
)

There's already a gtk-launch utility which does what you need.

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

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.

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

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.

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?

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

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

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

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?

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.

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

This is still the same with "gio open" as verified by me today on a bionic system

I apologize, I do not know this bug tracker well enough to reassign to the proper subsystem.

Ok, let's move this in GLib/GIO though not sure what to do with it due to the concerns from Comment 25...

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.

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

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

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

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.

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.

(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

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