requiring .desktop files to be executable ?

[R.F. Pels]

On Wed 18 February 2009 02.38.46 Michael Pyne wrote:

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

I'd say make it the same as a 'regular' executable:

- it is readable for the person trying to execute it
- it has the x bit set
- it is on a standard path (for .desktop files that is)
- in this case, it has a hash-bang path (treat it as a script)

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

Uhm, and what if the user is not the owner?

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

+1

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

Well, it looks like editing of menu's is out of the question as soon as 
a launcher .desktop needs to be in a specific path. Should one allow 
execution from .config/share/applications??? Isn't that a security risk? 
So now we only can let root change the content of desktop files, right? 
No more menu editor... for example.

> To figure this out we need to know what we use executable .desktop
> files for.

I'd say as launchers. Methinks the majority of desktop files in 
/usr/share/applications are launchers. 

-- 
R.F. Pels,          Boogerd 1, 1791 GW  Den Burg, Texel, The Netherlands
+31612914545        ruurd at kdemail.net      http://home.tiscali.nl/~ruurd