Re: [sane-devel] Sandboxing scanner applications
On 9/19/20 5:39 PM, Bastien Nocera wrote: I don't understand why you'd be telling me to write code to use saned in a way that it wasn't designed for and the net backend when earlier in the thread you told me that the SANE API didn't allow for ADF detection or PDF scanning. So which is it? ;) I actually didn't tell you to use saned. You probably have two possibilities now: 1) Reimplement sane-net/saned pair on a top of D-Bus transport 2) Define new scanning API on a top of D-Bus and implement it on a top of SANE (because only SANE provides you a collection of drivers) The difference between (1) and (2) is that in a case of (1) your D-Bus requests will mimic SANE API, while in a case of (2) it will not be so. Seems, printing portal API uses the second approach. You're the one that posited something completely wrong with regards to memory usage. I can just as well send image data along with the progress information so that we don't need to have a whole half-gig of data in flight at one point :) Do you plan to implement data streaming protocol on a top of D-Bus messaging? -- Wishes, Alexander Pevzner (p...@apevzner.com)
Re: [sane-devel] Sandboxing scanner applications
On Sat, 2020-09-19 at 18:01 +0200, Jörn-Ingo Weigert wrote: > Thanks for your opinion Bastien, please acknowledge mine too. > I don't see any sense to sandbox all and everything, just because you > can. > Better to fix problems and security issues, here related to Sane, > than just sandboxing it and hope, that sandboxing works... and that's > what sandboxing is about: running unchecked and therefore potentially > malicious software on a system. It's like saying drivers will start ramming their cars into one another because they wear seatbelts. I'm curious though, what part of the SANE project do you contribute to? Do you have any expertise writing code that could be sandboxed, whether through systemd's lockdown, or Snap or Flatpak sandboxing? > That doesn't mean, that the idea of a general, unified access over d- > bus to scanners may not be something to be developed. > > Bastien Nocera schrieb am Sa., 19. Sep. 2020, > 16:32: > > On Sat, 2020-09-19 at 14:03 +0200, Jörn-Ingo Weigert wrote: > > > Sandboxing is the loosing sign of developers who can't fix things > > and > > > don't know their product. > > > > You really don't have to send emails to the list if that's going to > > be > > your level of discourse. > >
Re: [sane-devel] Epson Perfection v370 Not Responding
On Sat, Sep 19, 2020 at 12:02:44PM -0700, C. Cook wrote: > You nailed it. It's the same root user permissions that got me last time. > > Network scanning just locks up the scanner (with proper permissions) so > I had to move the scanner to my main server and just use it by USB. > > Gotta fix those permissions by udev next time I reboot. Just a general udev tip: you don't need to reboot to apply rule changes. This command will do it: $ sudo udevadm control --reload-rules Then just unplug and replug the USB device and it should be covered by the new rules. --Sean
Re: [sane-devel] Epson Perfection v370 Not Responding
On 2020-09-19 10:48, Simon Matter wrote: >> I've installed the iScan software into CentOS 7.6 and the epkowa.conf >> backend is there. >> >> The scannerl shows up in lsusb and scanimage -L, but gscan2pdf, XSane, >> and iscan software can't find it. >> >> I can even scan using scanimage >test.jpg and the image comes out fine. >> But nothing else works. >> >> How can this be? > When doing scanimage and the other tools, was it always with the same user? > > Regards, > Simon You nailed it. It's the same root user permissions that got me last time. Network scanning just locks up the scanner (with proper permissions) so I had to move the scanner to my main server and just use it by USB. Gotta fix those permissions by udev next time I reboot.
Re: [sane-devel] Epson Perfection v370 Not Responding
> I've installed the iScan software into CentOS 7.6 and the epkowa.conf > backend is there. > > The scannerl shows up in lsusb and scanimage -L, but gscan2pdf, XSane, > and iscan software can't find it. > > I can even scan using scanimage >test.jpg and the image comes out fine. > But nothing else works. > > How can this be? When doing scanimage and the other tools, was it always with the same user? Regards, Simon
[sane-devel] Epson Perfection v370 Not Responding
I've installed the iScan software into CentOS 7.6 and the epkowa.conf backend is there. The scannerl shows up in lsusb and scanimage -L, but gscan2pdf, XSane, and iscan software can't find it. I can even scan using scanimage >test.jpg and the image comes out fine. But nothing else works. How can this be?
Re: [sane-devel] Sandboxing scanner applications
Thanks for your opinion Bastien, please acknowledge mine too. I don't see any sense to sandbox all and everything, just because you can. Better to fix problems and security issues, here related to Sane, than just sandboxing it and hope, that sandboxing works... and that's what sandboxing is about: running unchecked and therefore potentially malicious software on a system. That doesn't mean, that the idea of a general, unified access over d-bus to scanners may not be something to be developed. Bastien Nocera schrieb am Sa., 19. Sep. 2020, 16:32: > On Sat, 2020-09-19 at 14:03 +0200, Jörn-Ingo Weigert wrote: > > Sandboxing is the loosing sign of developers who can't fix things and > > don't know their product. > > You really don't have to send emails to the list if that's going to be > your level of discourse. > >
Re: [sane-devel] Sandboxing scanner applications
On Sat, 2020-09-19 at 07:55 -0400, Kelly Price wrote: > The question I have is... how strong is the Flatpak sandbox? Flatpak's sandbox is as strong as you set it up to be, stronger using Wayland than X11, stronger when there's no network access, stronger when there's no direct file access, etc. And it uses the same kernel technology as docker, and plenty of other container software. > Will it > allow such a deal? I don't understand what that means. > On Sat, Sep 19, 2020 at 7:42 AM Alexander Pevzner > wrote: > > > > On 9/19/20 12:25 PM, Bastien Nocera wrote: > > > Sealed memfds, passed via D-Bus, that's 1/2GB in all :) > > > > If D-Bus can pass an arbitrary file descriptor, it can be used to > > pass > > AF_UNIX socket, allowing usage of "network" transport without > > actual > > access to networking, and saving 1/2GB of memfs :-) > > > > -- > > > > Wishes, Alexander Pevzner (p...@apevzner.com) > > > >
Re: [sane-devel] Sandboxing scanner applications
On Sat, 2020-09-19 at 14:42 +0300, Alexander Pevzner wrote: > On 9/19/20 12:25 PM, Bastien Nocera wrote: > > Sealed memfds, passed via D-Bus, that's 1/2GB in all :) > > If D-Bus can pass an arbitrary file descriptor, it can be used to > pass > AF_UNIX socket, allowing usage of "network" transport without actual > access to networking, I could, but I would have to write the initial D-Bus negotiation, I would need to have saned always running, and this would just make it more difficult overall. I don't understand why you'd be telling me to write code to use saned in a way that it wasn't designed for and the net backend when earlier in the thread you told me that the SANE API didn't allow for ADF detection or PDF scanning. So which is it? ;) > and saving 1/2GB of memfs :-) You're the one that posited something completely wrong with regards to memory usage. I can just as well send image data along with the progress information so that we don't need to have a whole half-gig of data in flight at one point :)
Re: [sane-devel] Sandboxing scanner applications
On Sat, 2020-09-19 at 14:03 +0200, Jörn-Ingo Weigert wrote: > Sandboxing is the loosing sign of developers who can't fix things and > don't know their product. You really don't have to send emails to the list if that's going to be your level of discourse.
Re: [sane-devel] RESEND: Fujitsu fi5900c JPG compression fails with ADF Duplex
Wes, I'm going to need a more detailed log to figure this out. Also, there is no point in doing a command line redirection when doing a duplex scan, you will throw away the back page. SANE_DEBUG_FUJITSU=35 scanimage --resolution 100 --mode grayscale --source 'ADF Duplex' --compression JPEG --batch=out%d.jpg 2> 5900a.log If that doesn't demonstrate the error, you could try changing to color mode or increasing the resolution. I am trying to avoid that to keep the log size small. Then you will likely need to compress 5900a.log and send it to me directly. If it is too big, you will need to use something like dropbox to send it. allan On Fri, Sep 18, 2020 at 3:08 PM Wes Rishel wrote: > > Apparently my including debug created a messae that is too large. > > This time, the debugging output is in an attached zip. > > >> Working with 1.0.31. >> scanimage -V >> scanimage (sane-backends) 1.0.31; backend version 1.0.31 >> >> These work: >> scanimage --mode color --source 'ADF Duplex' > x.jpg (produces a .pnm file) >> scanimage --mode color --compression JPEG > x.jpg (produces a .jpg file) >> >> This produces a Segmntation fault/core dump: >> scanimage --mode color --source 'ADF Duplex' --compression JPEG > x.jpg >> >> So does this: >> scanimage --mode color --compression JPEG --source 'ADF Duplex' > x.jpg >> >> >> Attached is the output runnng the failing options with SANE_DEBUG_FUJITSU=15 >> -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
Re: [sane-devel] Sandboxing scanner applications
Sandboxing is the loosing sign of developers who can't fix things and don't know their product. Kelly Price schrieb am Sa., 19. Sep. 2020, 13:55: > The question I have is... how strong is the Flatpak sandbox? Will it > allow such a deal? > > On Sat, Sep 19, 2020 at 7:42 AM Alexander Pevzner > wrote: > > > > On 9/19/20 12:25 PM, Bastien Nocera wrote: > > > Sealed memfds, passed via D-Bus, that's 1/2GB in all :) > > > > If D-Bus can pass an arbitrary file descriptor, it can be used to pass > > AF_UNIX socket, allowing usage of "network" transport without actual > > access to networking, and saving 1/2GB of memfs :-) > > > > -- > > > > Wishes, Alexander Pevzner (p...@apevzner.com) > > > > > -- > Kelly "STrRedWolf" Price > http://redwolf.ws > >
Re: [sane-devel] Sandboxing scanner applications
The question I have is... how strong is the Flatpak sandbox? Will it allow such a deal? On Sat, Sep 19, 2020 at 7:42 AM Alexander Pevzner wrote: > > On 9/19/20 12:25 PM, Bastien Nocera wrote: > > Sealed memfds, passed via D-Bus, that's 1/2GB in all :) > > If D-Bus can pass an arbitrary file descriptor, it can be used to pass > AF_UNIX socket, allowing usage of "network" transport without actual > access to networking, and saving 1/2GB of memfs :-) > > -- > > Wishes, Alexander Pevzner (p...@apevzner.com) > -- Kelly "STrRedWolf" Price http://redwolf.ws
Re: [sane-devel] Sandboxing scanner applications
On 9/19/20 12:25 PM, Bastien Nocera wrote: Sealed memfds, passed via D-Bus, that's 1/2GB in all :) If D-Bus can pass an arbitrary file descriptor, it can be used to pass AF_UNIX socket, allowing usage of "network" transport without actual access to networking, and saving 1/2GB of memfs :-) -- Wishes, Alexander Pevzner (p...@apevzner.com)
Re: [sane-devel] Sandboxing scanner applications
On Sat, 2020-09-19 at 12:13 +0300, Alexander Pevzner wrote: > On 9/19/20 11:57 AM, Bastien Nocera wrote: > > D-Bus traffic is filtered, and we can select which services the > > application has access to. By default, only portals are accessible, > > nothing else, greatly reducing potential security and privacy > > issues. > > How do you plan to receive scanned images from scanner? > > Note, A4 color image at 1200 DPI is slightly less that 1/2 Gb. SANE > returns image uncompressed, so you probably need 1/2 Gb in scan > server, > 1/2 Gb in D-Bus daemon and 1/2 Gb in receiving application. Sealed memfds, passed via D-Bus, that's 1/2GB in all :) This is from 2014: https://lwn.net/Articles/593918/
Re: [sane-devel] Sandboxing scanner applications
On 9/19/20 11:57 AM, Bastien Nocera wrote: D-Bus traffic is filtered, and we can select which services the application has access to. By default, only portals are accessible, nothing else, greatly reducing potential security and privacy issues. How do you plan to receive scanned images from scanner? Note, A4 color image at 1200 DPI is slightly less that 1/2 Gb. SANE returns image uncompressed, so you probably need 1/2 Gb in scan server, 1/2 Gb in D-Bus daemon and 1/2 Gb in receiving application. And there are also larger paper sizes that A4, and higher resolutions that 1200. By contrast, if you are using some transport that allows streaming, and sane driver is well-written (i.e., it uncompresses the received image line-by-line, not entire image at once), you only need few tens of kilobytes to perform the image transfer. Note, Linux Printing is different from Linux scanning in that aspect, that images sent to printer are usually compressed. -- Wishes, Alexander Pevzner (p...@apevzner.com)
Re: [sane-devel] Sandboxing scanner applications
On Sat, 2020-09-19 at 00:24 -0700, Perry Hutchison wrote: > [Cc's dropped, because mailman complained of too many recipients] > > Bastien Nocera wrote: > > > ... using the "net" driver. It still requires punching a hole > > in the sandbox which shouldn't be necessary. > > Why is punching a hole for network::localhost -- allowing access > (via network) only to localhost, That's not actually possible without using net namespaces which aren't accessible by normal users. And your loopback interface still contains loads of services with potential security issues and private data, so even if just loopback access was possible, it still wouldn't be a good fit security or privacy-wise. > and not to any other host -- so > much worse than punching a hole for D-bus? D-Bus traffic is filtered, and we can select which services the application has access to. By default, only portals are accessible, nothing else, greatly reducing potential security and privacy issues.
Re: [sane-devel] Sandboxing scanner applications
[Cc's dropped, because mailman complained of too many recipients] Bastien Nocera wrote: > ... using the "net" driver. It still requires punching a hole > in the sandbox which shouldn't be necessary. Why is punching a hole for network::localhost -- allowing access (via network) only to localhost, and not to any other host -- so much worse than punching a hole for D-bus?
