Security issue with .desktop files revisited

Benedikt Meurer benny at
Wed Apr 12 17:21:23 EEST 2006

Francois Gouget wrote:
> 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.

You don't need the +x bit to add an emblem. You can also just add
emblems to all files of type application/x-desktop.

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

Shell scripts and binaries are a different story. .desktop files can
have a custom icon and custom name, and that's the real problem. You
cannot easily create a shell script that looks like a PNG file. To
repeat it once again, requiring the +x bit won't solve the real problem.

>  * .desktop files cannot be run without special action by the user

As said several times, it is still very easy to get the +x bit set on
the file, just put it into an archive. How should an archive manager
know whether it should leave the +x bit on the file when extracting.
There's no way to distinguish a malicious .desktop file from a safe
.desktop file. The +x bit can be set on both safe and unsafe files and
there's the real problem.

>  * .desktop files cannot rely on their icon to fool the user

This has nothing to do with +x being set or not. Instead it's the
question whether the file manager should display the Icon from the
.desktop file or the generic application/x-desktop icon.

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

While fixing the evaluation semantics of the Exec field would of course
be the best solution, it might be too complicated to get this right.
But, as suggested earlier, we could add some kind of signature to the
.desktop files, which allows applications to tell whether a .desktop
file can be trusted or not.


More information about the xdg mailing list