On Fri, 2020-09-18 at 18:22 +0300, Alexander Pevzner wrote: > 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.
We don't want applications to require network access to access a scanner. There's absolutely no reason why, say, "Simple Scan" needs to access the network, which it would need to if you wanted it to be able to access the loopback interface. > > 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. This isn't so much about Flatpak, but about portals that Snap also uses to implement sandboxing, even if the majority of Snaps don't implement any kind of sandboxing (AFAIK). 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. The application doesn't need network access to access a remote printer, for example, as the D-Bus service outside the sandbox is the one contacting the printer. Ditto for files access, etc. > > 1. There is a "Scanner Application", backed by SANE stack, which has > a > physical access to the scanner, running in the isolated Flatpack > environment 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. Do you expect user to run this "Scanner Application" manually before they want to scan and import it into an application? > 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 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. > > Who and in which terms will allow access of (2) to (1)? I don't think that we should need (1) to implement sandboxing of scanning applications that use the SANE API.
