Flatpaking of Paperwork: Issues with locale-specific files and scanner drivers

[Simon McVittie]

On Thu, 30 Aug 2018 at 14:00:26 +0200, Bastien Nocera wrote:
> Jerome posted a work-around on how to allow this to work:
> https://gitlab.gnome.org/World/OpenPaperwork/paperwork/blob/master/flatpak/README.markdown#debian-jessie-ubuntu-1604

This provides scanner access to everything that is in the initial
network namespace, not just Paperwork. In particular, Flatpak apps
with network access (Steam, Firefox, OpenArena, etc.) can now scan
your documents... not ideal.

> One thing I did not understand though was how the sane-based
> application would know to connect to localhost to access the scanners.

Presumably Paperwork as built for Flatpak is hard-coded to know that
it must do this?

> Possible solutions:
> - Add scanner portal that's the one getting a socket to the right port.
> That means apps can be network-sandboxed, and we implement the
> authorisation in the portal
> - But that means modifying libsane to ask via D-Bus instead of raw
> sockets directly.

If libsane can be made to do D-Bus (and not crash horribly[1]) then that
would be ideal.

> - Add Unix socket support, and allow access to it from within the
> sandbox, (and add a flatpak option to block non-Unix sockets?)

This is the next best thing if there can't be a portal. Path-based
(non-abstract) AF_UNIX sockets are much easier to sandbox than anything
else, because they can be bind-mounted into a foreign container - that's
how it works for D-Bus, Wayland, X11 and PulseAudio.

In general, if a library or server supports TCP remote $thing, it's
helpful for it to also support AF_UNIX local $thing; it'll be essentially
the same code and provides much easier access-control via permissions
(at least on Linux, where AF_UNIX sockets respect permissions). mpd is
a nice example of a protocol that was designed for TCP but can also now
do AF_UNIX.

A proxy outside the sandbox that speaks the saned network protocol on
an AF_UNIX socket (that is bind-mounted into cooperating Flatpak
sandboxes), and communicates with either saned or the scanner
directly, would also be an option.

    smcv

[1] I dimly remember having trouble in the past with libsane either
    calling dbus_shutdown(), which will crash everything else that is
    using libdbus in the same process, or having non-thread-safe patterns
    around its use of libdbus for Avahi; but I can't remember which and
    can't find the bug report now