[sane-devel] Sandboxing scanner applications
till.kamppeter at gmail.com
Fri Sep 18 18:37:25 BST 2020
On 17/09/2020 16:04, Bastien Nocera wrote:
> On Thu, 2020-09-17 at 15:38 +0200, Jörn-Ingo Weigert wrote:
>> Hi Bastian,nice idea. As SANE is already network capable to provide
>> connected scanners to the network,
>> (simply a network device) it make not really sense, to provide
>> sane(d) via Flatpak in my eyes.
> I have no plans on running saned inside the sandbox. It's about running
> a server on the outside of the sandbox, talking to the real hardware,
> so that applications don't need direct hardware access.
I was not talking about running saned in the sandbox, but letting the
client app talk IPP out of the sandbox to talk to the hardware driver in
>> however, having SANE-based applications like XSane/ scan-image as
>> Flatpak version, maybe a nice idea.
> Most of them are blocking on having a scanner portal, which is what
> this is about. For example:
> And paperwork needs access to all the devices, and ship its own sane-
> backends, which means it only works with the scanners supported by
This approach seems really awkward, ending up with having some GUI
applications support your scanner and other's not.
>> But for this you don't need to modify saned. ...
> You need to, if you don't want saned listening on the network, being
> auto-activatable, and being able to add a portal/proxy in between so
> that scanner access is a changeable permission.
So you want to convert saned into a D-Bus server for the sandboxed apps
to access and saned communicates with the actual scanners outside the
sandbox? So the scanned images get pumped through the D-Bus?
> We can't easily filter network calls, and most scanner apps don't need
> network access, so giving them network access opens the sandbox for no
> good reason.
So you are designing completely new, D-Bus-only protocols for printing
More information about the sane-devel