.desktop file security

[John Tapsell]

2009/2/25 Patryk Zawadzki <patrys at pld-linux.org>:
> On Wed, Feb 25, 2009 at 2:13 AM, Michael Pyne <mpyne at purinchu.net> wrote:
>> On Tuesday 24 February 2009, Patryk Zawadzki wrote:
>>> 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.
>> So what happens when the archive extractor actually supports xattr and now
>> there is executable-with-fancy bit trojan laying in the directory?
>
> It's safe to strip all the xattrs (by cooperating with the desktop's
> archiving tool of choice maintainers) without sacrificing any
> functionality. Scripts will continue to work, binaries will behave as
> they should. The only difference is clicking some of them will yield a
> "possibly unsafe content" warning. It's not safe to do the same thing
> with the +x flag as you'll break most of the source code tarballs.
> Thus +x/-x is not likely to work in a more generic case (not .desktop
> file specific).
>
> Also relying on just the +x flag will not work in collaborative
> environments. If I'm the file owner I get to control the +x flag. In
> such cases we still need an external metadata storage to take note of
> the file path, its hash (to detect changes) and whether it was trusted
> or not and if we implement such storage, why not allow just any other
> attributes (thus having a working xattrs fallback even if no
> filesystem support is present).

Are you suggesting some sort of collaborative situation where you want
some people to trust the .desktop file and others not?   I can't even
imagine such a situation.

John