Bug#408948: .volume might be needed too as well as full pathnames

[Loïc Minier]

On Wed, Feb 14, 2007, Josselin Mouette wrote:
> > > A more elegant way to fix network:// and the like is probably to give
> > > autogenerated files another MIME type, like
> > > application/x-desktop-virtual.
> >  I'm not sure we foresee all the consequences of such a change,
> We have to list all stuff using these virtual desktop files. A first
> search only lead me to the filechooser in libgnomeui, but there may be
> others.

 Precisely.  Actually, what you describe is much like the proposed
 solution to return a x-suspected-malware MIME type on suspicious
 .desktop files, just the other way around, but the x-suspected-malware
 solution would allow for more use cases such as:
 - handling of desktop files which do not use the correct extension
 - handling of other file types

 So, instead of introducing a new MIME type that should be trusted and
 changing all relevant applications to only trust that one, I would
 rather introduce a new MIME type which should not be trusted.

 We can even add the special URL handling for smb://, network:// etc. in
 gnome-vfs itself and return the .desktop MIME type for the allowed
 pathnames.

> The more I think about it, the more I'm convinced the best solution is
> to have a way to distinguish these virtual files from real ones. Relying
> later on the URI is too much error-prone and we will sooner or later
> find another vulnerability. However there may be other ways to
> distinguish them than changing the MIME type. I'll check whether we can
> rely on some of the fields of the GnomeVFSFileInfo API, but if it is not
> possible changing the MIME type looks like the best thing to do.

 I think it's safer but harder to change the MIME type, but my initial
 analysis was that it can be very complex since Nautilus isn't just
 requesting the MIME type from gnome-vfs2: for example it has logic to
 use the file data or the file extension depending on the speed of the
 underlying backend or whether the file is local etc.

 However, it's unsafe (especially at this point of the release cycle) to
 introduce a new MIME type AND to make all applications honor it at the
 same time; it's really easier to introduce a new MIME type which should
 NOT be handled by applications, such as "malware" MIME type of which no
 application know anything about!

> >  and I'm not sure why we would need to treat as "virtual" the
> >  .desktop files below computer:// and not below sshfs://.
> 
> Because sshfs doesn't generate such desktop files. Only the computer,
> dns-sd, smb and network methods do.

 My point is that sshfs generates virtual files exactly like
 "computer://" or "smb://": these are all _virtual_ file systems, so
 distinguishing a virtual desktop file from a real one is IMO a too
 dangerous concept.


 It seems to me what you're trying to express with the "virtual" desktop
 files is that these files can be trusted, but:
 1) it doesn't solve the problem completely as we still need to trust
    e.g. local .desktop files, other extensions, or some URL schemes, so
    it only covers files generated by smb://, computer://, or
    network:// and say we can trust these, but it doesn't help in
    expressing that we can trust some local .desktop files owned by the
    user
 2) it only covers .desktop files
 3) it is confusing to use the concept of "virtual" to express "secure";
    at least a x-trusted-desktop-file would express this in a clearer
    manner IMO

 I still think the safest is to introduce a MIME type on which NOT to
 act instead of a MIME type to act on, since all applications already
 handle the case where a MIME type is NOT supported.


 But this is all if we can change gnome-vfs2 to return these MIME types,
 and I think it's too hard.  Changing nautilus (and perhaps libgnomeui?)
 alone to special case some URIs seems more realistic and covers all
 problems we know about in terms of trust of .desktop files (the
 displaying still needs to be addressed).

> Well, we need nautilus to depend on the new libgnomevfs2-0 package, one
> way or another. The simplest way to do it now and forget it without bad
> consequences is to bump the shlibs.

 But the shlibs doesn't solve anything: it will still be possible to
 install the new libgnomevfs with packages built against the old one,
 while adding a conflicts in applications we adapt with older gnomevfs
 would prevent this.

 There are 413 rdeps on libgnomevfs2-0, and shlibs changes would be
 frowned upon at this point of the cycle, a conflict in nautilus and
 perhaps libgnomeui really seems less intrusive.

-- 
Loïc Minier <lool at dooz.org>