.desktop file security

[Alexander Larsson]

On Sat, 2009-02-21 at 18:07 -0500, Michael Pyne wrote:
> Hi all,
> 
> 
> 
> I'm just writing to let you know that I'm working on changing the
> handling of .desktop files for the next major version of KDE. The work
> itself is being tracked on kde-core-devel but a synopsis of the plan
> is:
> 
> 
> 
> When launching a .desktop file (which I'll refer to as a service), if
> any of the following conditions are true, the launch is permitted:
> 
> 
> 
> 1. The service is executable by the user
> 2. The service is owned by root (to handle the common case of
> system-installed files)
> 3. The service is contained in a standard service directory. Right now
> this means "xdgdata-apps" in addition to standard KDE service
> locations.

I'm doing something like this in gnome. ATM its just doing 1 and 3. What
is the common usecase for 2? Note, that my changes don't affect general
launching of desktop files in things like the menus, only those from the
file manager, and only for application launchers (not e.g. uri links).

Furthermore, I'm also doing:
4. Don't allow sniffing of desktop files, always require a .desktop
   extension.
5. For untrusted desktop files, don't show the custom icon and display
   name specified in the desktop file.

With this in place you can always detect when something weird is going
on by seeing the ".desktop" file and the standard icon for a launcher
instead of a faked icon/name.

> If the file is made executable automatically it is given a
> "#!/usr/bin/env xdg-open" header as well if it did not already have a
> #! header so that running the file from the command line will do the
> right thing.

While this is a "neat trick" I don't really think its a good idea. 
First of all it will conflict a bit with mimetype sniffing (of course,
this is disabled in the common file case as per above, but its useful in
e.g. a text editor for selecting syntax highlighting rules). 

Secondly, I've never ever heard any request for being able to launch
desktop files from other places, and in fact if we believe there is a
(small) risk in executing desktop files, why do we want to unnecessarily
enlarge the scope of this risk?

And Thirdly, spawning via xdg-open is generally not a good way to handle
desktop files. That way you can't e.g. apply startup notification, focus
stealing prevention, file argument expansion, etc. There is also the
risk that some app will accidentally launch the desktop file by spawning
a lot of unnecessary stuff instead of just using the right APIs to
launch desktop files that handles the stuff I listed.