Bug#902288: general: GNOME/nautilus thumbnail helper script from /usr/share/thumbnailers fails with ENOENT due to bwrap
Control: reassign -1 libgnome-desktop-3-17 3.28.2-1
Control: affects -1 + nautilus calibre
Control: tags -1 + moreinfo
Marco: please could you re-test this with the stable release of buster?
I think this may have been fixed during the freeze.
In general, "thumbnailers don't work" is probably too broad an issue to
be closed with a high level of confidence that *all* thumbnailers work
(although specific root causes, like not exposing /bin and /sbin on
non-usrmerged systems in the original #902288 report, can of course
be fixed).
Wrapping a sandboxing layer around existing code that was written
without sandboxing in mind is never going to be 100% transparent, but
it's a necessary step to mitigate exploitable bugs in thumbnailers or
the libraries they use. The same is true for non-bwrap strategies for
sandboxing potentially exploitable processes, like applying AppArmor or
SELinux policies to them, which will also sometimes not allow access to
a resource that the thumbnailer needs.
In buster, Nautilus and libgnome-desktop contain basically the same
code for sandboxed thumbnailing. This is obviously not ideal: the code
from libgnome-desktop was copied into Nautilus as a result of Nautilus
starting to gain GTK 4 support while libgnome-desktop is still tied to
GTK 3. In GNOME 3.33.x/3.34 (currently in experimental, but hopefully
coming to unstable soon), Nautilus dropped its local copy of this code
and went back to depending on libgnome-desktop.
If there are problems with a particular thumbnailer doing something
reasonable that ought to work (like relying on /bin and /sbin in the
original report of #902288), then I would recommend reporting them as
bugs in libgnome-desktop (marked as affecting the thumbnailer, and if
appropriate also nautilus), and the GNOME team will need to make sure that
any fixes in buster's libgnome-desktop also land in buster's nautilus.
If a thumbnailer is relying on doing something that partially-trusted
code in a sandbox should not be allowed to do (for example reading or
writing unrelated files in the home directory), then a bug against the
package containing the thumbnailer, marked as affecting nautilus and
libgnome-desktop, would be more appropriate.
If it isn't clear whether the thumbnailer's actions are reasonable or
not, it is possible to mark bugs as existing in both packages equally
while they are being investigated, and the bug can be reassigned to
the problematic package when the root cause has been found.
On Sun, 24 Jun 2018 at 16:41:45 +0200, Marco Ippolito wrote:
> --symlink usr/bin /bin
> --symlink usr/sbin /sbin
This particular issue (not having /bin and /sbin in the sandbox on systems
that have not undergone the /usr merge) appears to be the same thing as
Launchpad bug #1807127, and should be fixed in nautilus 3.30.5-2 (for
the code path going through nautilus) and in gnome-desktop3 3.30.2-2
(for the code path going through libgnome-desktop). This will hopefully
have addressed the original report involving calibre - please check?
On Sun, 24 Jun 2018 at 18:47:07 +0200, Marco Ippolito wrote:
> Do package maintainers run tests for thumbnailers?
I don't think the GNOME team have the resources to carry out systematic
testing of all the available thumbnailers.
If the maintainers of packages that provide thumbnailers were to
add automated tests of the combination of the thumbnailer and the
relevant part of GNOME using autopkgtest (probably best done using
libgnome-desktop, since a library is going to be easier to control
programmatically than Nautilus), then those tests would automatically
be re-run every time there is a new libgnome-desktop version, and test
failures would block automatic migration of the new GNOME version from
unstable to testing.
smcv
Reply to: