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

[Bastien Nocera]

On Fri, 2017-10-13 at 16:27 +0200, Bastien Nocera wrote:
> 
<snip>
> I'm not sure it's that different to expecting other sandbox-aware
> daemons to be installed in the distribution.
> 
> You also would not be able to use any hotplug support. So you can't
> launch your scanner app and then plug it in, because of the way the
> devices are set up in the sandbox.
> 
> Ideally, saned is pretty much exactly what the doctor ordered, and
> already supports everything using the sane libraries directly
> supports
> (enumeration, accessing all the features of the scanner), has a
> stable
> ABI/protocol and maybe supports authorisation in a modular way that
> can
> be integrated in gnome-shell.
> 
> And though saned wouldn't live in the sandbox, we can still lock it
> down quite a fair bit with systemd's lockdown features.
> 
> Do any of the SANE/saned developers care to comment?

Reviving this thread.

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

One thing I did not understand though was how the sane-based
application would know to connect to localhost to access the scanners.
This should really work without configuration, or be hard-coded (can
saned proxy to the saned on another machine for the networked scanning
case?)

To setup saned, I would imagine that we might want to add a scanners
panel in desktops, so the local devices can be configured that way, and
the sandboxed apps only get access to the scanning itself.

Problems:
- No authorisation question
- Requires the network to be opened to only access localhost
- Difficult to know if saned is running, and correctly configured

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.

- Do kernel-based network filtering on the Flatpak side, might give us
the ability to implement a portal too?

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

All in all, I think that we might want to bring the conversation to the
sane mailing-list.

It might be that writing a new saned that does just what we want it to
is the way to go (it's about 3k lines, mostly of C stuff that's trivial
in GLib), but we'll need to get some frontend library changes in as
well, for applications to use.