.desktop files and security
There is been an ongoing level of concern over these files, most recently voiced by Sam Watkins on the XDG mailing list. The issue that that .desktop files are, for all practical purposes, shell scripts capable of doing anything that the user can do. But they do not have to be marked as executable, and they have complete control over how they are presented on the desktop. A .desktop file can show up as a document or image file, but actually be some sort of hostile script. A user, hoping only to view a file which has shown up on the desktop, may end up running something entirely different.
A number of ways of addressing the issue have been proposed. The simplest, perhaps, is to require that .desktop files have execute permission to be launched. Since setting that bit requires an explicit action on the part of the user, a hostile icon cannot be put directly onto the desktop by, for example, a file downloaded via a web browser. Some people have objected that .desktop files are not actually executables - they cannot be run from the command line. Putting a suitable #! line at the beginning of the file would fix that, however.
Another possibility would be to mark known-good .desktop files with an extended attribute. If an attempt was made to launch an unmarked file, a suitably scary dialog would be put up and confirmation required from the user. Or, .desktop files with executable content could be restricted in the set of icons they could use, so that, at least, the fact that a program would be run would be obvious. Or some sort of global system database could keep track of the trusted .desktop files.
Perhaps the most elaborate suggestion is to run all .desktop programs (and perhaps others) in a tightly-restricted sandbox with little access to the rest of the system. With some work, the desktop environment could be reworked to make most things work transparently for users. For example, selecting a file in a file-browser dialog would grant the right to access that file to the associated application. The Plash project has made progress toward the implementation of such a system.
Which of these solutions will be adopted, if any, remains to be seen. It
is not clear that everybody sees a real problem with the capabilities of
.desktop files. Experience has shown, however, that even difficult and
unlikely attack vectors will be exploited eventually. It would be a shame
if the adoption of desktop Linux were to be held back by security concerns.