Setuid and setgid (and setcap where it exists) are the only ways to elevate privileges. Other than through this mechanism, a process can relinquish privileges, but never gain them. Therefore you would not be able to do anything that requires additional privileges.
For example, the programs su and sudo need to be able to run commands as any user. Therefore they need to run as root, no matter which user called them.
Another example is ping. TCP and UDP sockets are accessible to any user, because these protocols have a notion of ports, and a process can take control of a port (which is called binding it), so the kernel knows where to send the packets. ICMP has no such notion, so only programs running as root (or with the appropriate capability) are allowed to request that ICMP packets are dispatched to them. In order for any user to be able to run ping, the ping program needs to have an additional privilege, so it's setuid root (or setcap).
For an example of group privileges, consider a game that stores local high scores in a file. Since only actual high scores achieved by users should be stored in the score file, the score file must not be writable by players. Only the game program must be allowed to write to the score file. So the game program is made setgid games, and the score file is writable by the group games but not by players.
There is an alternative approach to elevating permissions, which is to start programs that require additional privileges from a privileged launcher program. When a user wants to perform a task that requires additional privileges, he runs a front-end program which uses some form of inter-process communication to perform the privileged action. This works well for some use cases such as ping (one ping program to parse options and report progress, and a ping-backend service that sends and receives packets), but not for other use cases such as the game high score file.
NFS was invented in the Unix world and so understands traditional Unix permissions out of the box. (The ACL of modern unix systems are another matter, but recent implementations of NFS should cope with them.)
Samba was invented in the IBM/Microsoft PC world, to exchange files with systems that had no permissions beyond read-only/read-write. It is now native to Windows. By default, Samba does not transmit Unix permissions. Depending on the configuration, either all files are marked executable (which is annoying) or all files (except directories) are marked non-executable (which is annoying).
There are various extensions to the Samba/CIFS protocol that make it more suited for Unix use. Try enabling Unix extensions in the server configuration:
[global]
unix extensions = yes
Best Answer
One obvious reason a
.desktophas not necessarily the executable bit set is these files were not intended to be executable in the first place. A.desktopfile 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
.desktopfile 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.desktopfiles 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.desktopfiles with the executable bit set are taken into account by the desktop environment.Just turning a non executable file like a
.desktopone 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 itbashorshor 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
.desktopfiles and should point to the right command designed to handle them, xdg-open, like for example Thunderbird does here:In this case, executing the
.desktopfile will do whateverxdg-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.