We need to fix the evaluation semantics of Exec, not write a bunch of
easily-avoidable workarounds.
I don't see anything to be fixed in the 'evaluation semantics of Exec'
that would help solve this problem. Maybe if you have a concrete
proposal that can be discussed further. When writing your proposal,
please keep in mind that it must be flexible enough to allow stuff like
Exec=/opt/cxoffice/bin/wine --workdir "C:////Program Files////QuickTime
" --check --cx-app "C:////Program
Files////QuickTime////QuickTimePlayer.exe"
(all on one line of course) while not allowing
Exec=rm -rf /
While fixing the evaluation semantics of the Exec field would of course
be the best solution, it might be too complicated to get this right.
But, as suggested earlier, we could add some kind of signature to the
.desktop files, which allows applications to tell whether a .desktop
file can be trusted or not.
And who is going to attach these signatures?
I would say a more appropriate approach would be to classify the command
in a few cases:
1) The command executed is a program/script in the user's home-directory
or some other user-writable location(which increases the risk of it
being malware)
2) The command executed is an program/script in /bin, which are
generally more dangerous than other executables(rm, mv and others reside
there)
3) The command executed is a program/script in /usr/bin, which are
generally(but not always ofcourse) safer to use.
This would of course introduce a need to extract the real command from
the exec-line in the .desktop file but that shouldn't be too hard.
Anyway, I think +x is more a nuisance than improved safety. As the
situation now is, .desktop files aren't more executable than .sh files
without a +x bit set; those too can be executed by doing 'sh script.sh',
same as .desktop files with a different parser.
-- Egbert
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
