.desktop file security

[Alexander Larsson]

On Tue, 2009-02-24 at 11:13 +0000, John Tapsell wrote:
> 2009/2/24 Alexander Larsson <alexl at redhat.com>:
> > On Sat, 2009-02-21 at 18:07 -0500, Michael Pyne wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I'm just writing to let you know that I'm working on changing the
> >> handling of .desktop files for the next major version of KDE. The work
> >> itself is being tracked on kde-core-devel but a synopsis of the plan
> >> is:
> >>
> >>
> >>
> >> When launching a .desktop file (which I'll refer to as a service), if
> >> any of the following conditions are true, the launch is permitted:
> >>
> >>
> >>
> >> 1. The service is executable by the user
> >> 2. The service is owned by root (to handle the common case of
> >> system-installed files)
> >> 3. The service is contained in a standard service directory. Right now
> >> this means "xdgdata-apps" in addition to standard KDE service
> >> locations.
> >
> > I'm doing something like this in gnome. ATM its just doing 1 and 3. What
> > is the common usecase for 2? Note, that my changes don't affect general
> > launching of desktop files in things like the menus, only those from the
> > file manager, and only for application launchers (not e.g. uri links).
> >
> > Furthermore, I'm also doing:
> > 4. Don't allow sniffing of desktop files, always require a .desktop
> >   extension.
> > 5. For untrusted desktop files, don't show the custom icon and display
> >   name specified in the desktop file.
> >
> > With this in place you can always detect when something weird is going
> > on by seeing the ".desktop" file and the standard icon for a launcher
> > instead of a faked icon/name.
> >
> >> If the file is made executable automatically it is given a
> >> "#!/usr/bin/env xdg-open" header as well if it did not already have a
> >> #! header so that running the file from the command line will do the
> >> right thing.
> >
> > While this is a "neat trick" I don't really think its a good idea.
> > First of all it will conflict a bit with mimetype sniffing (of course,
> > this is disabled in the common file case as per above, but its useful in
> > e.g. a text editor for selecting syntax highlighting rules).
> 
> It's dangerous not to.  If it's marked as executable, and you execute
> it, it will try to be parsed by bash.  Most of the time this will just
> generate lots of "file not found" errors as bash tries to understand
> it, but it seems pretty dangerous to rely on this!

Really, even if there is no #!/bin/sh ? How does it know to pick bash as
the interpreter for files like this?