.desktop file security

[Claes H]

On Tue, Feb 24, 2009 at 3:05 PM, Patryk Zawadzki <patrys at pld-linux.org> wrote:
> On Tue, Feb 24, 2009 at 1:40 PM, Simon McVittie
> <simon.mcvittie at collabora.co.uk> wrote:
>> On Tue, 24 Feb 2009 at 13:29:05 +0100, Alexander Larsson wrote:
>>> On Tue, 2009-02-24 at 11:13 +0000, John Tapsell wrote:
>>> > It's dangerous not to.  If it's marked as executable, and you execute
>>> > it, it will try to be parsed by bash.  Most of the time this will just
>>> > generate lots of "file not found" errors as bash tries to understand
>>> > it, but it seems pretty dangerous to rely on this!
>>>
>>> Really, even if there is no #!/bin/sh ? How does it know to pick bash as
>>> the interpreter for files like this?
>> More accurately, /bin/sh will try to parse it (executable files that
>> have no #! and no magic number recognised by the kernel are executed with
>> /bin/sh). /bin/sh happens to be bash on most distributions, at least by
>> default (but is dash on Ubuntu and on some Debian systems).
>
> ...and pdksh in other places.
>
> What comes to mind is why would we want to use the executable bit for
> non-executable files? I don't want my shell to tab-complete commands
> that are not executable, be it .desktop, .mp3 or .foobar. If we
> absolutely need to use the +x flag, use it only if extended attrs are
> not provided or not available.
>
> Also using extended filesystem attributes (or some other metadata
> storage) gives you the additional protection from "downloaded a
> tarball / uncompressed to desktop / the file was compressed as
> executable / now I have two computer icons" kind of scenarios.
>
> --
> Patryk Zawadzki

I strongly agree. Unless the executable bit is actually used for
execution of the file by the kernel (for example using hashbang-path
with xdg-open), I think another mechanism, such as extended
attributes, is preferable. I don't think the executable bit should be
overloaded as a generic flag.

/Claes