The freedesktop organization defines the standard for .desktop files. Unfortunately it defines not the permissions of the file (see freedesktop mailinglist) and software is distributed with

a) executable .desktop files
b) non executable .desktop files
c) mixed a) and b) in one software package. 

This is not very satisfying for Linux distributors, who aim to provide a consistent system. I want to use the broad audience of sx, to find out

what advantage has a .desktop file without execution bit? Is there any reason for not having all .desktop files executable if the filesystem alows it?

Are there known security problems? Are there programs which have difficulties with executable .desktop files?


One obvious reason a .desktop has not necessarily the executable bit set is these files were not intended to be executable in the first place. A .desktop file contains metadata the tell the desktop environment how to associate programs to file types but was never designed to be executed itself.

However, as a .desktop file indirectly tell the graphic environment what to execute, it has an indirect capacity to launch whatever program is defined in it, opening the door to exploits. To avoid malicious .desktop files to be responsible to the launch of hostile or unwanted programs, KDE and gnome developers introduced a custom hack that somewhat deviates the intended Unix file execution permission purpose to add a security layer. With this new layer, only .desktop files with the executable bit set are taken into account by the desktop environment.

Just turning a non executable file like a .desktop one to an executable one would be a questionable practice because it introduces a risk. Non binary executable files with no shebang are executed by a shell (be it bash or sh or whatever). Asking the shell to execute a file which is not a shell script has unpredictable results.

To avoid that issue, a shebang needs to be present in the .desktop files and should point to the right command designed to handle them, xdg-open, like for example Thunderbird does here:

#!/usr/bin/env xdg-open
[Desktop Entry]
Comment=Send and Receive Email

In this case, executing the .desktop file will do whatever xdg-open (and your Desktop Environment) believe is the right thing to do, possibly just opening the file with a browser or a text editor which might not be what you expect.

  • 2
    That's rather the result of a longer debate as I pointed out here (btw, the accepted answer to that question is utterly wrong...) and it is also implemented in GNOME (and possibly other DEs but I wouldn't know). However, these "security measures" (i.e. shebang and chmod+x) do not apply to desktop files that come from upstream and are placed in $XDG_DATA_DIRS/applications only to local files placed in $XDG_DATA_HOME/applications – don_crissti Jun 25 '17 at 13:16
  • @don_crissti Thanks for the information, answer adjusted. – jlliagre Jun 25 '17 at 16:34

Desktop files are used for more than handling URLs and launching applications. The current FreeDesktop specification lists three different kinds of desktop files:

This specification defines 3 types of desktop entries: Application (type 1), Link (type 2) and Directory (type 3). To allow the addition of new types in the future, implementations should ignore desktop entries with an unknown type.


Directory files (type 3) are mainly used for custom icons and menus but the Dolphin file manager also uses them to e.g. enable/disable thumbnail previews of images.

Link-type desktop files can point to arbitrary URLs. For example, the example-content package in Ubuntu puts this type 2 desktop file in the home directory by default:

[Desktop Entry]
_Comment=Example content for Ubuntu


Double-clicking on this desktop file in a file manager will navigate to the /usr/share/example-content/ folder.

Link-type desktop files can also point to files. For example, here's one that opens the manual for the LaTeX hyperref package:

[Desktop Entry]
Name=hyperref manual

also used elsewhere:


Link-type desktop files have also been used to open HTTP URLs in the browser:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.