Security issue with .desktop files revisited

Carsten Haitzler (The Rasterman) raster at
Fri Mar 24 03:57:59 EET 2006

On Thu, 23 Mar 2006 17:42:09 +0000 Mike Hearn <mike at> babbled:

> On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
> > I don't see how it is any different from .desktop files with:
> > Exec=/bin/sh -c 'cd ; rm -rf *'
> > (don't run that!)
> It's not really, except you can write longer programs and even run
> arbitrary ELF programs too.
> > It looks like the best alternative.
> > 
> > But why should we require users to go the properties and turn it
> > executable? If you've got a legitimate .desktop file, it already follows
> > the guidelines, which may include being executable or not.
> Well, this guideline doesn't exist yet, so no .desktop files will have
> it. And those programs out there that make .desktop files (on the users
> desktop for instance) will break.
> Perhaps a more complicated system would work better ... +x bit is only
> needed if the Exec line does not contain an absolute path?

personally i see this as a moot point. i agree - .desktop files run stuff. expect them to. if u don't trust them - inspect them. it's a matter of trust in the end. next peopke will say source tarballs are a security risk because to compile u run ./configure which is a non-trivial shell script (basically impossible to double check to see its ok) and then produce programs that can be equally evil.

i do see though the use for a "caution" lump of code. inspect the exec field on load - if its a simple "executable" name (or full path) (ie is is just a full path to an already existing executable, OR its n executable IN your path already) and NOTHING else - then it should be left just as is. if it contains any shell meta char ($ | % etc. etc.) instantly put a warning flag on the icon "something fishy here" UNTIL the user OKAYS the file (they inspect the exec line and say it's ok). you can get fancier by maybe allowing up to 1 or 2 command parameters to the executable as long as they are simple etc. etc. and match some accepted norm. maybe this might be an intermediate "dodgey" stage which is normally ok 99% of the time. anyway - this is not a matter i think for the .desktop format or spec to handle - but apps on top to implement a users preference in security paranoia and then indicate thins it KNOWS are perfectly safe, vs things that may or may not be and you have okay'ed or not.

> > If we require the latter to be executable, why not the former?
> Well, I was never convinced the +x bit was a good idea, problem is that if
> it's off this doesn't give the user any information they didn't already
> know. So why would they change their decision? They double clicked it,
> right? The best you could do is some kind of warning, "This file is a
> program. If you continue, it may do anything you can do. Only proceed if
> you trust the origin of this file." But people often ignore or click
> through such warnings without really considering them.
> thanks -mike
> _______________________________________________
> xdg mailing list
> xdg at

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at
Tokyo, Japan (東京 日本)

More information about the xdg mailing list