On 9/18/20 6:01 PM, Bastien Nocera wrote:
So the application inside the sandbox would ship with sane-airscan
backend, and use this protocol, over the network, to communicate with
the fake "airscan" scanner running outside the sandbox, right?
Over loopback in most cases.
Having every scanner application access the network is going to be a
problem, much like having to punch of network hole to get full CUPS
access is a problem right now. Is there going to be another transport?
AFAIK, loobback is not usually protected by firewall.
Using TCP/IP stack instead of AF_UNIX sockets has an advantage to allow
using of Avahi daemon for local discovery of present devices. With
alternative transport, some alternative discovery method should be
designed and implemented.
Note, I said authorisation, not authentication. "Authorisation" is when
the user chooses to allow or disallow access by the application. It's
the method, coupled with user intent, used by Flatpak portals to check
whether an application is allowed to use a particular resource outside
the sandbox.
Neither me not Till seems to be familiar with Flatpak, so I would
appreciate if provide a bit more detailed explanation of how the things
expected to work.
1. There is a "Scanner Application", backed by SANE stack, which has a
physical access to the scanner, running in the isolated Flatpack environment
2. There is some Client program, that wants to scan (for example, xsane
or simple-scan, or even libreoffice). It may or may not be running in a
sandbox
Who and in which terms will allow access of (2) to (1)?
--
Wishes, Alexander Pevzner ([email protected])
