requiring .desktop files to be executable ?

[David Faure]

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

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

> >> If a desktop file is run that doesn't fit these requirement, we warn
> >> the user harshly, set the x-bit if they agree anyway, and continue to
> >> run.
> >
> > I'm not sure I like the idea of having an Override button in the prompt but
> > definitely we need to include some way of having the user be able to fix it
> > (I just think it's better if it takes more than one click, i.e. click to
> > open the .desktop file properties or something).
> 
> I agree somewhat, but we need to have this an option for now.
> 
> For example, googleearth is installed on my system as a .desktop file
> on my desktop.  If this just stops working, that's not so great.  But
> if it pops up a warning message the first time I click (from now on),
> that's not so bad.

The msgbox button that fixes the problem reduces security greatly compared
to having to open the properties dialog -- but improves usability greatly too ;-)
The Windows warning about downloaded executables is also a simple msgbox
though, so I suppose that's enough.

> > Also, what do we actually break on existing systems by making this change?

Existing .desktop files on the user's desktop, or in their home directory for instance.

> > Do we need to make like a kconf_update script for upgrades or would the
> > existing exceptions we have work? To figure this out we need to know what we
> > use executable .desktop files for.

I don't like the idea of a kconf_update script (which will write stuff into the desktop files).
In fact it's not really made for desktop files at all. Anyway (even if writing 
an upgrade script without kconf_update), the recursive find for desktop files 
would kill performance on first login, too...

> I think with the setup I propose, it wouldn't break existing systems.
> Especially if the 'worst case' is a once off pop-up that warns the
> user.  I would prefer to avoid requiring any update script.

Agreed.

It won't make all users happy to get a Windows-like "do you really want to run this"
msgbox, but as Waldo often said, security is not optional...

> So..  don't suppose I can persuade anyone to actually do the work ? :)

Well... I can add it to my TODO...

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