[sane-devel] Sandboxing scanner applications

[Alexander Pevzner]

On 9/18/20 6:44 PM, Bastien Nocera wrote:

> A portal is a D-Bus service running outside the sandbox offering
> services to the sandbox application, such as file chooser, printing,
> screenshots, localisation, etc. Sandboxed applications call a well-
> known D-Bus service, and wait for an answer. The D-Bus service asks the
> user about the resource to be shared, gives it back to the application.

Currently, to print a document, application (with a help of libcups) 
connects to the CUPS server via TCP or AF_UNIX socket, creates print 
job, using IPP protocol.

AFAIK, there is no implementation of the printing infrastructure for 
Linux, that sends document to be printed via D-Bus.

If application, that wants to print (say, Firefox) runs in one sandbox, 
and print server runs in another sandbox, they still can use existent 
socket-based infrastructure for communication, and reimplementing this 
infrastructure on a top of D-Bus requires a lot of effort.

And of we can use socket-based communication for printing, why not use 
it for scanning as well?

> Is "Scanner Application" a GUI app, a plugin, a network server? Is this
> what's going to offer the IPP Scan extension to apps? I must say I'm
> utterly confused by the name.

Well, the terminology is not quite clear, I agree.

The idea comes from OpenPrinting group. Till can explain it much better, 
but I'll explain in short.

To allow sandboxing of print drivers, there were introduced a concept of 
"Printer Applications". Printer application is, essentially, as a daemon 
that communicates with the printer on a hardware-specific way and 
exposes a standard "IPP Everywhere" printer to the localhost.

So the CUPS server will not need to be able to print to something else 
that to the "IPP Everywhere" printers, i.e., CUPS will always print in a 
"driverless" mode. All hardware-specific stuff will come as a collection 
of Printer Applications, and these Applications can be sandboxed.

https://openprinting.github.io/upcoming-technologies/01-printer-application/

The similar thing in a context of scanning was initially called "Printer 
application for scanning", but because it sounds ugly, the term quickly 
changed to "Scanner Application".

So "Scanner Application" is not GUI application, but instead a system 
daemon, that exposes a scanner using standard (IPP-scan) protocol.

> Do you expect user to run this "Scanner Application" manually before
> they want to scan and import it into an application?

Of course, no, it will be started among other daemons.

> This client program would most likely run inside a sandbox. If it
> didn't, it would be able to access the local scanner in the same way it
> does now.

SANE drivers are essentially are dynamic libraries (shared object in ELF 
terms). Sandboxed shared libraries cannot be accessed from outside of 
the sandbox that owns them.

I can imagine "mixed" installation, where SANE drivers come sandboxed, 
while simple-scan installed from a usual RPM or DEB package. This 
"legacy-way" installed simple-scan will not be able to access SANE 
drivers directly.

-- 

	Wishes, Alexander Pevzner (pzz at apevzner.com)