After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 518757 - support thumbnails on mounts / avoid leaking information from encrypted filesystems
support thumbnails on mounts / avoid leaking information from encrypted files...
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Alexander Larsson
gtkdev
: 381910 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-02-26 02:12 UTC by David Zeuthen (not reading bugmail)
Modified: 2018-05-24 11:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gio patch (5.62 KB, patch)
2008-02-26 02:13 UTC, David Zeuthen (not reading bugmail)
none Details | Review
gvfs patch (1.16 KB, patch)
2008-02-26 02:13 UTC, David Zeuthen (not reading bugmail)
none Details | Review
libgnomeui patch (9.92 KB, patch)
2008-02-26 02:16 UTC, David Zeuthen (not reading bugmail)
none Details | Review

Description David Zeuthen (not reading bugmail) 2008-02-26 02:12:28 UTC
The thumbnail spec supports the notion of local thumbnail repositories

 http://web.archive.org/web/20070824034129/jens.triq.net/thumbnail-spec/local.html

This is interesting to use on encrypted media to avoid leaking thumbnails of documents into $HOME which may be cleartext. In fact, as we do this today, this is somewhat important to fix as some people might call it a grave security bug. I've added the 'security' keywork just in case; feel free to remove it.

Will attach patches against gio, gvfs and libgnomeui to implement this.
Comment 1 David Zeuthen (not reading bugmail) 2008-02-26 02:13:25 UTC
Created attachment 105952 [details] [review]
gio patch

There's room for optimization here.
Comment 2 David Zeuthen (not reading bugmail) 2008-02-26 02:13:54 UTC
Created attachment 105953 [details] [review]
gvfs patch
Comment 3 David Zeuthen (not reading bugmail) 2008-02-26 02:16:36 UTC
Created attachment 105954 [details] [review]
libgnomeui patch

It'll only work on local mounts for now; didn't port the code over to gio just yet.

It's an open question if whether we want to allow gnome_thumbnail_factory_lookup() to return an URI. E.g. "gphoto2://[usb:001,042]/.thumblocal/normal/51a95447c63733b6c892c322a9eae329.png". I don't know.
Comment 4 David Zeuthen (not reading bugmail) 2008-02-26 02:22:31 UTC
These patches combined plugs leaking information via thumbnails for LUKS volumes. Please consider these patches for GNOME 2.22.

The thumbnailing spec needs revision (plus hosting on fd.o but that's another matter) to change the language such that it's allowed to populate .thumblocal on encrypted mounts (to avoid this security bug). I can bring that up on xdg-list.

Also, there's some interesting applications of .thumblocal

 - the gphoto2 backend can use this to provide a fast path to thumbnails by
   providing a virtualized .thumblocal directory. When nautilus reads a
   thumbnail from there it can then save it in $HOME/.thumbnails. This provides
   an ultra fast path for thumbnailing as the gphoto2 backend can fetch
   thumbnails directly from the camera (it's part of the PTP protocol)

 - nautilus-cd-burner could include an option "[x] Include thumbnails on disc"
Comment 5 Alexander Larsson 2008-02-27 11:52:32 UTC
I read the spec like the .thumblocal directory is supposed to be in each folder, not in the toplevel dir. But its not very clear. But take this:
 
> The filename of the thumbnail is the md5sum of the filename part of the URI. 
> Because the URI is possibly not constant, only the filename part of the URI 
> should be used, no directory or protocol parts.

It says "no directory" parts.

Anyway, we're very close to release and should focus on relese blockers, not feature creep.
Comment 6 David Zeuthen (not reading bugmail) 2008-02-27 18:14:49 UTC
(In reply to comment #5)
> I read the spec like the .thumblocal directory is supposed to be in each
> folder, not in the toplevel dir. But its not very clear. But take this:
> 
> > The filename of the thumbnail is the md5sum of the filename part of the URI. 
> > Because the URI is possibly not constant, only the filename part of the URI 
> > should be used, no directory or protocol parts.
> 
> It says "no directory" parts.

Then the spec is broken and needs to be fixed. Obviously omitting the directory name is never going to work, not even for CD-ROM which is their canonical example. I think with "no directory" it means the directory parts leading up to the mount point. 

> Anyway, we're very close to release and should focus on relese blockers, not
> feature creep.

I can appreciate the fact we're close to a release and may want to punt this to 2.23. That's fine. But I really wish you didn't call a security bug that involves leaking information from an encrypted mount "feature creep". If you think about it, it's actually quite bad what we are doing...
Comment 7 David Zeuthen (not reading bugmail) 2008-02-27 18:21:34 UTC
(In reply to comment #5)
> I read the spec like the .thumblocal directory is supposed to be in each
> folder, not in the toplevel dir. 

Oh, I didn't get this impression from reading the spec at all.

> But its not very clear. 

I agree. Maybe we should ask on xdg-list? Certainly the spec needs to work for encrypted mounts otherwise we can't fix this bug.
Comment 8 David Zeuthen (not reading bugmail) 2008-02-27 19:01:44 UTC
Actually thinking about it having .thumblocal in each folder might make more sense. I'm thinking mostly about shiny future storage pool based file systems where you can e.g. select that only folder ~/Documents is encrypted (things like ZFS or btrfs comes to mind).

(also, this approach means that the get_thumbnail_attributes() in glocalfileinfo.c would be slightly faster; no need to get the enclosing mount so we'd save a lot of stats going up the chain.)

I'm fine with redoing the patches to do this; would mean that we'd need g_file_is_encrypted() in addition (or replacing) g_mount_is_encrypted().

Anyway, need to clarify the thumbnail spec first; I'll ask on xdg-list.

So this is definitely 2.23 stuff. Thanks for your feedback so far.
Comment 9 David Zeuthen (not reading bugmail) 2008-02-27 19:16:44 UTC
I've asked here

 http://lists.freedesktop.org/archives/xdg/2008-February/009274.html
Comment 10 Christian Neumair 2008-02-28 14:48:35 UTC
> Actually thinking about it having .thumblocal in each folder might make more
sense.

I don't know. The current approach has the advantage that clearing your thumbnail cache is very simple, and you never leak information to other users through shared files. If all users share a .thumblocal folder with lax permission rights, isn't this even worse?

Note that we also leak information through our metadata machine: By seeing what URIs have already been browsed by the user, you can conclude what subfolders exist in a directory that cannot be listed (has -x set). Of course, that's also available through shell history, but many shells allow to exclude commands from being stored in the history.

best regards,
 Christian Neumair
Comment 11 Alexander Larsson 2008-02-28 14:53:24 UTC
No need for a g_file_is_encrypted() call. Just use g_file_query_filesystem_info
on the path. 

I call it "feature creep", because this is something we already do today, so
keeping doing it is not a regression. And while its not ideal its far less of a
problem than some other issues we have like things crashing for normal users
that we need to fix to be usable at all.

Anyway, there are reasons for not allowing writing to the .thumblocal
directory. There are generally permissions problems for it so that you often
can't write to it. And if you do then you might have to make the directory
world writable which is bad. Also, if multiple people have write access to a
.thumblocal directory then you can place files there that are autoloaded by
other users, which is a possible slight security issue. 

You also have to make the thumbnails world readable, as otherwise only one user
can read them, but other users would use the same name and can't thumbnail.
However, being world readable means you leak a thumbnail of a file that may not
be world readable itself. Even if you propagate the actual file permissions to
the thumbnail that info may go stale if the file later changes permissions.

Its also very hard to clean these directories up, as they are scattered all
over the place and the files in them are not always deleted when the
corresponding file is deleted (especially since the dirs are hidden).

A better approach would be to store the thumbnails encrypted in $home, and
store a random cookie used for the encryption in the encrypted filesystem
(.thumbcookie?). Only if you can read the cookiefile on the encrypted
filesystem can you decrypt the thumbnail.
Comment 12 nodiscc 2012-07-02 01:00:11 UTC
Bug 381910 is closely related to this (duplicate?)
Comment 13 Cosimo Cecchi 2012-07-12 13:28:37 UTC
*** Bug 381910 has been marked as a duplicate of this bug. ***
Comment 14 GNOME Infrastructure Team 2018-05-24 11:20:33 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/127.