requiring .desktop files to be executable ?

Jaime jtamate at gmail.com
Wed Feb 18 12:04:00 GMT 2009


Forgive me if this is a dup (but is not shown in the mailing list archives).

Why not let an anti-troyan, anti-virus (clamav?) or whatever check
every .desktop file searching for malicious code in the exec line?
They are the experts in those kinds of treats.
For example, user created .desktop files with the command "rm -r
$HOME/.*". (why not?)

This can be done when the .desktop file is going to be interpreted.
And only show a messagebox
when the antivirus detects some problem in the .desktop file (or
commands associated).

Best Regards.

2009/2/18 John Tapsell <johnflux at gmail.com>:
> 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 ;-)
>>
>>> 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.
>




More information about the kde-core-devel mailing list