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 ([email protected])
