Hey Steve, On Fri, 2014-05-23 at 17:14 +0000, Dodier-Lazaro, Steve wrote: > Hi, > > > I've discussed with a few people recently on IRC about providing file > previews in my sandbox-traversing File Choosers or in Allan's new > Content Selection Dialogs, and also about running untrusted > thumbnailers for use in Nautilus. I'm curious whether the file preview > back-end could reuse thumbnailers and if custom file preview functions > could be entirely replaced with standalone thumbnailer executables.
They cannot. The thumbnailers don't use any UI widgets, and provide none of the necessary niceties to be usable as file previews. What you might think as usable when previewing a PDF will completely fall apart when previewing a video. There's also no "thumbnailer" for audio :) > In an OS with sandboxed apps, one would really want to also sandbox > thumbnailers: they run with the desktop environment's privileges and > could potentially steal every file they're given (or more). I've had a > quick glimpse at the GNOME Thumbnailer and it seems very easy to > sandbox it. Instead of directly launching the untrusted thumbnailer, > you'd give its path as a parameter to a generic Sandboxed Worker. There's already some code in Fedora to use SELinux to provide some minimal sandboxing of thumbnailers, not allowing some of them to write anywhere but in the thumbnail directory for example. > The worker could be a well-known D-Bus name or user systemd service > that sets up a Docker/LXC container, makes a read-only bind of the > input file's path and a write-only bind to the output file's path. It > could have a switch just like systemd services to remove networking, > and possibly start with very a limited system interface (using > seccomp2, with options to allow extra syscalls depending on the > worker's task). You're getting deep into the technical implementation here, and I'm not sure that should be done before defining the necessary interface. FWIW, you don't need bind mounts to do this, you'd pass a read-only fd through D-Bus, and avoid all kind of side-effects. But that would mean that thumbnailers that use network information to provide a thumbnail wouldn't work (downloading game or video covers for example), those that use local databases wouldn't work either (like audio file covers cached with libmediaart not being accessible to the thumbnailer), etc. I think it's important to list all the possible types of thumbnailers, which accesses they need, and then discuss the possible implementations. <snip> Cheers _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
