requiring .desktop files to be executable ?

[David Faure]

On Thursday 19 February 2009, John Tapsell wrote:
> 2009/2/18 Michael Pyne <mpyne at purinchu.net>:
> > On Wednesday 18 February 2009, David Faure wrote:
> >> On Wednesday 18 February 2009, John Tapsell wrote:
> >> > 2009/2/18 David Faure <faure at kde.org>:
> >> > > On Wednesday 18 February 2009, John Tapsell wrote:
> >> > >> 2009/2/18 Michael Pyne <mpyne at purinchu.net>:
> >> > >> > On Tuesday 17 February 2009, John Tapsell wrote:
> >> > >> >> Let's not let this thread die again. It is really important to
> >> > >> >> come
> >> > >> >> to a solution.
> >> > >> >>
> >> > >> >> How about allowing execution if any of following conditions are
> >> > >> >> set: * x-bit it set
> >> > >> >> * owned by root
> >> > >> >> * In a standard path
> >> > >
> >> > > Sounds good to me.
> >> > >
> >> > >> > Why allow both root exception and std path exception? It seems to
> >> > >> > me
> >> > >> > that they cover the same case.
> >> > >
> >> > > No they don't, my $KDEDIR is not owned by root, and yet I don't want
> >> > > to
> >> > > have to +x every single desktop in it ;-)
> >
> > I thought that we would be counting KDEDIRS and XDG_DATA_DIRS (or whichever
> > is correct) as part of the "standard paths" and not /usr (which should
> > already be present).
> >
> >> > >> How about allowing execution if any of following conditions are set:
> >> > >> * x-bit it set
> >> > >> * owned by root, and not writable by current user (if they aren't
> >> > >> root) * In a standard path, not writable by current user (if they
> >> > >> aren't root)
> >> > >
> >> > > I don't see what's "bad" about writable by current user.
> >> > > And again this would break the user-owned $KDEDIR case.
> >> >
> >> > I was just thinking of the case where Desktop is a fat32 partition
> >> > (usb key, nfs, or something) so the files are all owned by root and
> >> > are writable.
> >>
> >> We could remove the "owned by root" from the initial list above, then.
> >> Users rarely go in /usr/something/notstandard and click on .desktop
> >> files... I think it's enough to allow execution of desktop files from
> >> `kde4-config --path xdgdata-apps`.
> >
> > Exactly what I'm talking about actually :)
> 
> If you have a .desktop file that is owned by root and is not writable
> by the user - surely we can trust that it can be run?  Especially
> since the user _can't_ make it executable.
> 
> There's a lot of different types of setup, and it wouldn't surprise me
> if there are installations where admins put .desktop files on peoples
> desktop.

(OTOH the admin could +x the desktop file too ;-)

> Maybe look at it the other way round.  Is there any reason to _not_
> trust a .desktop file that was owned by root and not writable by the
> user?

OK, with both conditions it doesn't break the case of a FAT partition
(where everything is owned by root *and* writable by the user).

So we arrive at the following whitelist:
 * x-bit is set
 * in a standard path (xdgdata-apps, apps, services)    (*)
 * owned by root and not writable by user

(*) I guess we should not add the Autostart folder to it, to protect the user
from "save this file into your autostart folder", although, well, that would
be a rather suspicious instruction in the first place...

-- 
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).