Security issue with .desktop files revisited

Francois Gouget fgouget at
Wed Apr 12 15:46:25 EEST 2006

Rodney Dawes wrote:
> Better yet, let's not encourage people to turn .desktop files into
> scripts. As has been expressed MANY times in this thread, requiring +x
> and a special tool that doesn't evaluate Exec any differently thatn we
> are currently evaluating Exec, doesn't solve the problem. It is very
> easy to ship a .desktop file to someone that is already +x.

In order to run an executable one must have the execute permissions for 
that executable. Whether you like it or not .desktop files are 
executables and, as such, running them ('opening' them in desktop 
parlance) should require that you have the relevant execute permissions.

Requiring +x on .desktop files also makes it possible to add an emblem 
to the icon of those that lack it, and/or to issue a warning when the 
user tries to run them. Thus this also protects users from .desktop 
files that have a misleading icon.

Sure there are many ways to make a .desktop file executable. But that's 
completely besides the point, because once we require +x on .desktop 
files they represent no more of a threat than shell scripts and ELF 
binaries. So any solution to that particular problem must also take care 
of those otherwise it is useless. By the way, such a solution exists, it 
relies on Extended Attributes, and as has been said before will take a 
long time before it can really be deployed.

So to summarize the current situation:
  * .desktop files are the only type of executable that can be run with 
a single click immediately after download
  * they can specify a misleading icon to fool the user

And after the we require .desktop files to have +x:
  * .desktop files cannot be run without special action by the user
  * .desktop files cannot rely on their icon to fool the user

> We need to fix the evaluation semantics of Exec, not write a bunch of
> easily-avoidable workarounds.

I don't see anything to be fixed in the 'evaluation semantics of Exec' 
that would help solve this problem. Maybe if you have a concrete 
proposal that can be discussed further. When writing your proposal, 
please keep in mind that it must be flexible enough to allow stuff like

Exec=/opt/cxoffice/bin/wine --workdir "C:////Program Files////QuickTime
" --check --cx-app "C:////Program Files////QuickTime////QuickTimePlayer.exe"

(all on one line of course) while not allowing

Exec=rm -rf /

Francois Gouget
fgouget at

More information about the xdg mailing list