Last week, an old security issue in desktop environments went through a
widely public discussion (including on slashdot). As I said, this
issue is not new, but there seem to be no action on the upstream to
After taking an extensive look in all the history of this discussion,
I've oppened a new bug report in nautilus upstream, in addition to
the two bug reports that were already openned in Debian.
As I made myself very clear in the bug reports, I don't think there is
any good excuse to execute '.desktop' files without them having the x
bit set. For those who didn't follow the discussion, this can make a
fishing attack very much easy in both Gnome and KDE, since iceweasel
downloads files directly to the user Desktop.
The only really sane solution is behave like any *nix like Operating
System and consider .desktop files to be executables, and thus require
the x bit to execute them. Since .desktop is really the desktop variant
for a .sh.
In order to do that, a few other things would be required:
1) An "interpreter" for .desktop files, that can be used in the shbang
of that files. [This is already done, look below]
2) Modify the packages providing .desktop files in order to both add
the shbang and deploy the files with the x bit set. [This is the next
3) Modify nautilus so that .desktop files are not handled specially.
They would be executed if they were executables or be shown in some way
(properties dialog) if not.
4) Modify nautilus DnD code so that permissions should be preserved
when dragging local .desktop files in mount points listed in /etc/fstab
and owned by root or the user himself. Otherwise, umask must be
enforced, meaning "strict by default, relax where needed".
5) Provide a "one-shot" migration process at the first time the user
runs the new nautilus, so the user can review any file owned by himself
in his Desktop or menu. This would only happen once, so this wouldn't
become a "standard procedure" to the user.
6) Do the same in KDE and other Desktop Environments that
interpret .desktop files.
As I consider this issue to be very much important, I already took the
time to work item 1. The xdg-utils package already contains the
"xdg-launch" utility in its git repo and should be uploaded soon, which
leads us to the step 2, and once that is completed all the other items
can happen, but item 2 is a blocker for everything else.
I considered mass-filling bugs about this issue, and maybe I will at
some point, but for start, I thought it would be nice to get this issue
P.S.: It has been used as an excuse the fact that extracting an archive
file could result in .desktop files with the +x bit in the user home
directory. I think that is a separated issue, and have filed a bug in
file-roller upstream to make "preserve permissions" off by default.