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

[Bastien Nocera]

On Thu, 2018-08-30 at 14:35 +0100, Simon McVittie wrote:
> 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.

Yeah, it's a work-around. I'd rather have that for now, than the
application not being available at all. We might want to have a link in
the description of those apps to mention the work-around needed on the
host side though. Jerome?

> > 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?

Yeah, Jerome answered after I sent this mail. There's a sane.conf file
that makes it point to 127.0.0.1 as the "scanner".

> > 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.

If we were to modify saned and libsane to support AF_UNIX, I'd rather
jump directly to D-Bus, we'll see how that ends up working. Hopefully
we can implement this in the upstream versions, and we can simplify
some of that code by using GLib/GIO.

I'll drop a mail to see whether that's something the upstream is
interested in.

Cheers

>     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

Yeah, dbus usage in some libraries can be pretty iffy.