requiring .desktop files to be executable ?
David Faure
faure at kde.org
Tue Feb 24 23:06:06 GMT 2009
On Tuesday 24 February 2009, Roland Harnau wrote:
> 2009/2/23, David Faure <faure at kde.org>:
> > On Monday 23 February 2009, Roland Harnau wrote:
>
> >> Your commit addresses the direct security threat, but the question
> >> remains in what way should the spec be extended. Requiring .desktop
> >> files to have executable bit and shebang line dependent on an
> >> optional key will for sure cause some inconsinstencies.
> >
> > It's not about the optional key Exec, it's about Type=Application desktop
> > files. Ok that key is optional too, but Application is the default value. There are
> > only a few kinds of desktop files, this security thing is about the Application
> > kind. The plasma desktop files you are talking about are Type=Service desktop
> > files, so those are completely unrelated to this (they certainly never end up in
> > klauncher or KRun anyway).
>
> Desktop files with Type=Service are not related to the
> Type=Application (which should imply the Exec key) the ones by this
> security issue, but they are clearly of the same file type. Setting
> the executable bit not by file type but by some internal criteria
> leads some oddities especially in the migration phase, e.g. a .desktop
> file without exec bit can be
>
> (1) not of Type=Application
> (2) legacy with Type=Application
> (3) possible harmful with Type=Application
>
> and it is not easily possible to keep them apart, at least not
> without parsing and applying some complex logic in the lines of what
> Michael did.
Sure. So?
"A file named foo.txt could contain text or something else and it's not
easily possible to keep them apart without parsing it". Obviously.
There is no migration tool, users are supposed to make executable by hand
the few desktop files that they use from $HOME or Desktop... Only they can
tell if it's (1) (2) or (3), that's the whole point of the security measure.
> Yes, but this usage is somewhat discouraged by the standard UI and
> perhaps only an issue if folderview is used as desktop containment.
No, you can still have standalone icons too, e.g. by drag-n-dropping files onto the desktop.
And "somewhat discouraged" doesn't mean that people don't do it.
> The Desktop folder is itself poses a problem because it is not only
> used as location where several apps install their .desktop files, it
> is also used as standard download folder (e.g. by Firefox). So, what
> is worse - to remove this option completely or to nag the user to
> death by a series of message box attacks?
You want to remove the possibility of starting apps from a desktop file altogether?
That's not going to happen. It's a useful feature, let the people who want it, have it
(e.g. if I make scripts for my wife, in a project folder, and I want to give them
a nicer icon than the "shell script" icon; just one example). Obviously when I would
set up something like that I would chmod +x the file (if KDE >= 4.3), and everything
will work as intended. No "message box attacks" on her, I'll be the one getting
the msgbox if I forget to chmod in the first place.
Security by removing useful features is not really the goal.
--
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel
mailing list