requiring .desktop files to be executable ?

[John Tapsell]

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
>
> Why allow both root exception and std path exception? It seems to me that
> they cover the same case.

Yes - I wanted to be double sure.  Sometimes people install to
non-standard paths (/opt for example.  Typical for universities to
install KDE here) and sometimes they might not be owned by root.  One
slight adjustment I'd make though is:

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)

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

We could have the override button for KDE 4.3 and remove the override
button in the prompt in KDE 4.4 or so, if we felt it wasn't so good.

>
> Also, what do we actually break on existing systems by making this change?
> 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 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.

John