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

[Jerome Flesch]

30 août 2018 17:31 "Bastien Nocera" <hadess at hadess.net> a écrit:

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

Actually, for now I plan to add a note directly in Paperwork. Mathieu Jourdan has even made some nice wireframes for that:
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/issues/704


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

For reference:
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/blob/master/flatpak/shared-modules/sane-backends-1.0.27.json#L14



>> 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.
> 
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak