Re: USB scanners and PR 50340
Thomas Klausner writes: > On Sun, Mar 20, 2016 at 08:24:33AM -0400, Greg Troxel wrote: >> That's not entirely clear. In theory programs that use that, rather >> than how SANE has changed, might still want it. Whether there are any >> such programs that any actual user wants to use is unclear. > > Do you know any such program? I thought there was one, but I can't find it now. Proably the SCSI scanner interface is more likely to be used than uscanner. I'm not objecting to outright removal. I was just pointing out that I lacked enough information to do it, whereas I was confident that it was in the interest of users to flip the default. signature.asc Description: PGP signature
Re: USB scanners and PR 50340
On Fri, 18 Mar 2016, Gary Duzan wrote: =>Dave Tyson writes: => =>> I note that PR 50340 has been closed and with the latest pkgsrc =>>under current (amd64) my Mustek 1200 UB scanner seems to work OK =>>- but I have comment out the uscanner device in the kernel and use =>>it as a ugen device. It seems that this is the 'new world order' =>>and the sane backend code to handle uscanner devices is deprecated. =>>Given this is the case is there any point in still keeping the =>> =>> uscanner* at uhub? port ? =>> =>> in GENERIC? => =>Quite possibly we should remove (comment out) uscanner in GENERIC. =>ulpt is more controversial, but cups wants to use libusb too. => =>> I am of the same opinion as the PR originator that it is easier =>>to control access permissions with a uscanner device rather than =>>having to open up a whole raft of ugen devices, but I guess the =>>sane developers feel that using libusb makes support easier... => =>Perhaps if we had something called uscanner that would match scanners =>and that libusb would fine, we could have the permissions management of =>direct matching but the cope-with-the-rest-of-the-world benefit of =>libusb. Can we not build some sort of bus-like device to which both the specialized and generic devices can attach which prevents opening both at the same time? An alternative is to have a method to detach the kernel driver so that you can revert to ugen access (and probably method to reattach too). This is true for all usb devices (e.g. uvideo, umass, etc.). libusb has the following API, but we don't have the kernel support for it. int libusb_kernel_driver_active (libusb_device_handle *dev, int interface_number) Determine if a kernel driver is active on an interface. int libusb_detach_kernel_driver (libusb_device_handle *dev, int interface_number) Detach a kernel driver from an interface. int libusb_attach_kernel_driver (libusb_device_handle *dev, int interface_number) Re-attach an interface's kernel driver, which was previously detached using libusb_detach_kernel_driver(). int libusb_set_auto_detach_kernel_driver (libusb_device_handle *dev, int enable) Being able to detach kernel drivers would allow for USB remoting (e.g. http://usbip.sourceforge.net/ or Citrix Receiver). It would aid development of drivers with rump too. -- Stephen
Re: USB scanners and PR 50340
On Sun, Mar 20, 2016 at 08:24:33AM -0400, Greg Troxel wrote: > That's not entirely clear. In theory programs that use that, rather > than how SANE has changed, might still want it. Whether there are any > such programs that any actual user wants to use is unclear. Do you know any such program? Thomas
Re: USB scanners and PR 50340
Nick Hudson writes: > On 03/19/16 19:12, Greg Troxel wrote: >> Martin Husemann writes: >> >>> On Sat, Mar 19, 2016 at 07:17:50PM +0200, Andreas Gustafsson wrote: I think we should disable uscanner in GENERIC now. I have been doing that on my own systems for years, as uscanner has never worked for me. The permissions issues can be fixed later. >>> I agree. >> OK - I have the change staged, but I'm going to do test builds of a few >> arches before commiting, to avoid embarrassment. > IS there any reason to keep uscanner(4)/usscanner(4) now? That's not entirely clear. In theory programs that use that, rather than how SANE has changed, might still want it. Whether there are any such programs that any actual user wants to use is unclear. (There's a similar conversation about ulpt, but much harder.) signature.asc Description: PGP signature
Re: USB scanners and PR 50340
On 03/19/16 19:12, Greg Troxel wrote: Martin Husemann writes: On Sat, Mar 19, 2016 at 07:17:50PM +0200, Andreas Gustafsson wrote: I think we should disable uscanner in GENERIC now. I have been doing that on my own systems for years, as uscanner has never worked for me. The permissions issues can be fixed later. I agree. OK - I have the change staged, but I'm going to do test builds of a few arches before commiting, to avoid embarrassment. IS there any reason to keep uscanner(4)/usscanner(4) now? Nick
Re: USB scanners and PR 50340
On Sat, Mar 19, 2016 at 05:12:11PM +0100, Martin Husemann wrote: > > The ACL would be evaluated in addition to filesystem > > permissions and would match attributes like class/vendor/product/serial/... > > The driver and/or a sysctl setting could determine how an empty > > ACL is handled, probably defaulting to the current behaviour. > > Whet is the entitled entitiy of the ACL? uid:gid tuples? Something like if device proplist attributes match some rule user 1 is granted read / write / execute user 2 is granted read / write / execute user 3 is granted read / write / execute ... group 1 is granted read / write / execute group 2 is granted read / write / execute group 3 is granted read / write / execute ... other is granted read / write / execute The effective permission would be a logical AND of the filesystem permission and the access list. The match rule would be something like device-parent == uhub2 device-driver == umass serialnumber == "12412341241234234" The device proplist could be extended to provide things like vendor/product/description to allow matching of unknown devices. > Is the console owner handled differently? Nothing is done automatically. When you are considered the console owner (e.g. by xdm TakeConsole) then a script would just set the appropriate access list (instead of chmod/chown the /dev/XXX nodes). Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB scanners and PR 50340
Martin Husemann writes: > On Sat, Mar 19, 2016 at 07:17:50PM +0200, Andreas Gustafsson wrote: >> I think we should disable uscanner in GENERIC now. I have been doing >> that on my own systems for years, as uscanner has never worked for me. >> The permissions issues can be fixed later. > > I agree. OK - I have the change staged, but I'm going to do test builds of a few arches before commiting, to avoid embarrassment. signature.asc Description: PGP signature
Re: USB scanners and PR 50340
On Sat, Mar 19, 2016 at 07:17:50PM +0200, Andreas Gustafsson wrote: > I think we should disable uscanner in GENERIC now. I have been doing > that on my own systems for years, as uscanner has never worked for me. > The permissions issues can be fixed later. I agree. Martin
Re: USB scanners and PR 50340
Dave Tyson writes: > I note that PR 50340 has been closed and with the latest pkgsrc under current > (amd64) my Mustek 1200 UB scanner seems to work OK - but I have comment out > the uscanner device in the kernel and use it as a ugen device. It seems that > this is the 'new world order' and the sane backend code to handle uscanner > devices is deprecated. Given this is the case is there any point in still > keeping the > > uscanner* at uhub? port ? > > in GENERIC? Quite possibly we should remove (comment out) uscanner in GENERIC. ulpt is more controversial, but cups wants to use libusb too. > I am of the same opinion as the PR originator that it is easier to control > access permissions with a uscanner device rather than having to open up a > whole raft of ugen devices, but I guess the sane developers feel that using > libusb makes support easier... Perhaps if we had something called uscanner that would match scanners and that libusb would fine, we could have the permissions management of direct matching but the cope-with-the-rest-of-the-world benefit of libusb. signature.asc Description: PGP signature
Re: USB scanners and PR 50340
Greg Troxel wrote: > Do people think that solving the permissions issue should be related to > disabling uscanner in */GENERIC? Here's the list of what I'd change: I think we should disable uscanner in GENERIC now. I have been doing that on my own systems for years, as uscanner has never worked for me. The permissions issues can be fixed later. -- Andreas Gustafsson, g...@gson.org
Re: USB scanners and PR 50340
Do people think that solving the permissions issue should be related to disabling uscanner in */GENERIC? Here's the list of what I'd change: ./alpha/conf/GENERIC:uscanner* at uhub? port ? ./amd64/conf/GENERIC:uscanner* at uhub? port ? ./amd64/conf/XEN3_DOM0:uscanner* at uhub? port ? ./cats/conf/GENERIC:uscanner* at uhub? port ? ./evbarm/conf/HDL_G:uscanner* at uhub? port ? ./evbarm/conf/HPT5325:uscanner* at uhub? port ? ./evbarm/conf/SHEEVAPLUG:uscanner* at uhub? port ? ./evbarm/conf/SMDK2410:uscanner* at uhub? port ? ./evbppc/conf/OPENBLOCKS266_OPT:uscanner* at uhub? port ? ./evbppc/conf/PMPPC:uscanner* at uhub? port ? ./hpcmips/conf/GENERIC:uscanner* at uhub? port ? ./hpcmips/conf/TX3922:uscanner* at uhub? port ? ./hpcmips/conf/VR41XX:uscanner* at uhub? port ? ./hppa/conf/GENERIC:uscanner* at uhub? port ? ./i386/conf/GENERIC:uscanner* at uhub? port ? ./i386/conf/XEN3_DOM0:uscanner* at uhub? port ? ./landisk/conf/GENERIC:uscanner* at uhub? port ? ./macppc/conf/GENERIC:uscanner* at uhub? port ? # USB scanners ./sgimips/conf/GENERIC32_IP3x:uscanner* at uhub? port ? ./sparc64/conf/GENERIC:uscanner* at uhub? port ? found via find src/sys/arch -type f | xargs egrep ^uscanner | egrep -v /majors signature.asc Description: PGP signature
Re: USB scanners and PR 50340
On Sat, Mar 19, 2016 at 03:12:08PM +0100, Michael van Elst wrote: > Changing ownerships of the filesystem entries isn't sufficient. > After all some ugen* can be changed quickly. I expected devpubd to deal with that for us - not sure what you mean here. > I'd prefer either some separate ACLs specific to USB devices or > even some generic device property that could be maintained using > drvctl. I wouldn't make it usb specific (why should we?) but maybe implement it on a driver-by-driver basis starting with ugen and umass. > The ACL would be evaluated in addition to filesystem > permissions and would match attributes like class/vendor/product/serial/... > The driver and/or a sysctl setting could determine how an empty > ACL is handled, probably defaulting to the current behaviour. Whet is the entitled entitiy of the ACL? uid:gid tuples? Is the console owner handled differently? Martin
Re: USB scanners and PR 50340
On Sat, Mar 19, 2016 at 11:29:09AM +0100, Martin Husemann wrote: > On Sat, Mar 19, 2016 at 08:45:59AM +, Michael van Elst wrote: > > That's a can of worms. You don't even know what a particular ugen* > > device is until you opened and queried it. > > Here is my original suggestion: > > http://mail-index.netbsd.org/tech-userlevel/2015/10/25/msg009389.html Changing ownerships of the filesystem entries isn't sufficient. After all some ugen* can be changed quickly. I'd prefer either some separate ACLs specific to USB devices or even some generic device property that could be maintained using drvctl. The ACL would be evaluated in addition to filesystem permissions and would match attributes like class/vendor/product/serial/... The driver and/or a sysctl setting could determine how an empty ACL is handled, probably defaulting to the current behaviour. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB scanners and PR 50340
On Sat, Mar 19, 2016 at 08:45:59AM +, Michael van Elst wrote: > That's a can of worms. You don't even know what a particular ugen* > device is until you opened and queried it. Here is my original suggestion: http://mail-index.netbsd.org/tech-userlevel/2015/10/25/msg009389.html Martin
Re: USB scanners and PR 50340
On Saturday 19 Mar 2016 08:45:59 you wrote: > mar...@duskware.de (Martin Husemann) writes: > >I tried to get the non-libusb (i.e. uscanner0) version to work with latest > >sane-backends, but failed. > > Does it work in FreeBSD (with /dev/usb/scanner0) ? No, I think FreeBSD only provide assess via the ugen interface (according to the online FreeBSD handbook). > > >Instead we should improve our device ownership handling in a more > >general way. Jared suggested dynamic groups (i.e. the kernel magically > >adding the owner of /dev/console to a special group "consoleuser" or > >something similar), but there are other alternatives. > > That's a can of worms. You don't even know what a particular ugen* > device is until you opened and queried it. FreeBSD suggest creating a usb group and using devfs.rules to control access to ugen devices. IMHO this unworkable as the ugen a device like a scannet attached as will vary depending on other USB devices attached at the time. Dave -- = Phone: 07805784357 Open Source O/S: www.netbsd.org Caving: http://www.wirralcavinggroup.org.uk =
Re: USB scanners and PR 50340
Date:Fri, 18 Mar 2016 20:48:07 -0400 From:"Gary Duzan" Message-ID: <20160319004807.2b63d115...@xen1.duzan.org> | In Message , |Greg Troxel wrote: | =>Perhaps if we had something called uscanner that would match scanners | =>and that libusb would fine, we could have the permissions management of | =>direct matching but the cope-with-the-rest-of-the-world benefit of | =>libusb. I was going to suggest something similar, a driver that connects to ugen internally, so it has the same interface as ugen does for applications (or libusb) to use, but which only works with (only allows access to) usb devices with particular characteristics (such as scanners, or printers, or modems, or UPSs) which could be controlled by matching manufacturer, class, or whatever works... Something like this should be not very hard to do, as it doesn't have to deal with anything complex (and leaves all the real work to the ugen driver underneath, combined with application code above). It would allow permissions to be set on the /dev/xxx entry that are appropriate for the device, without knowing which USB port the device would happen to get plugged into, and without accidentally allowing access to a umass or similar device. |Can we not build some sort of bus-like device to which both the | specialized and generic devices can attach which prevents opening | both at the same time? That I suspect would be quite a bit more work, though it might be useful to allow access to one scanner (or printer, or whatever) via the specialised driver for user code that works that way, or via ugen (and libusb presumably) for user code written that way - whichever one the user wants to use that day.What isn't so clear is just how many people would actually need, and use, that if it was developed, rather than just settling for one application (and hence one access method) for each of scanners, printers, etc. That is, would it really be worth the effort needed to make it work? kre
Re: USB scanners and PR 50340
mar...@duskware.de (Martin Husemann) writes: >I tried to get the non-libusb (i.e. uscanner0) version to work with latest >sane-backends, but failed. Does it work in FreeBSD (with /dev/usb/scanner0) ? >Instead we should improve our device ownership handling in a more >general way. Jared suggested dynamic groups (i.e. the kernel magically >adding the owner of /dev/console to a special group "consoleuser" or >something similar), but there are other alternatives. That's a can of worms. You don't even know what a particular ugen* device is until you opened and queried it. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB scanners and PR 50340
On Fri, Mar 18, 2016 at 09:04:32PM +, Dave Tyson wrote: > I am of the same opinion as the PR originator that it is easier to control > access permissions with a uscanner device rather than having to open up a > whole raft of ugen devices, but I guess the sane developers feel that using > libusb makes support easier... With latest pkgsrc it even works on sparc64 again ;-) I tried to get the non-libusb (i.e. uscanner0) version to work with latest sane-backends, but failed. So I support removal of uscanner* (commenting it out) from all GENERIC kernels. Instead we should improve our device ownership handling in a more general way. Jared suggested dynamic groups (i.e. the kernel magically adding the owner of /dev/console to a special group "consoleuser" or something similar), but there are other alternatives. Martin
USB scanners and PR 50340
I note that PR 50340 has been closed and with the latest pkgsrc under current (amd64) my Mustek 1200 UB scanner seems to work OK - but I have comment out the uscanner device in the kernel and use it as a ugen device. It seems that this is the 'new world order' and the sane backend code to handle uscanner devices is deprecated. Given this is the case is there any point in still keeping the uscanner* at uhub? port ? in GENERIC? I am of the same opinion as the PR originator that it is easier to control access permissions with a uscanner device rather than having to open up a whole raft of ugen devices, but I guess the sane developers feel that using libusb makes support easier... Dave -- = Phone: 07805784357 Open Source O/S: www.netbsd.org Caving: http://www.wirralcavinggroup.org.uk =
Re: USB scanners and PR 50340
In Message , Greg Troxel wrote: =>Dave Tyson writes: => =>> I note that PR 50340 has been closed and with the latest pkgsrc =>>under current (amd64) my Mustek 1200 UB scanner seems to work OK =>>- but I have comment out the uscanner device in the kernel and use =>>it as a ugen device. It seems that this is the 'new world order' =>>and the sane backend code to handle uscanner devices is deprecated. =>>Given this is the case is there any point in still keeping the =>> =>> uscanner* at uhub? port ? =>> =>> in GENERIC? => =>Quite possibly we should remove (comment out) uscanner in GENERIC. =>ulpt is more controversial, but cups wants to use libusb too. => =>> I am of the same opinion as the PR originator that it is easier =>>to control access permissions with a uscanner device rather than =>>having to open up a whole raft of ugen devices, but I guess the =>>sane developers feel that using libusb makes support easier... => =>Perhaps if we had something called uscanner that would match scanners =>and that libusb would fine, we could have the permissions management of =>direct matching but the cope-with-the-rest-of-the-world benefit of =>libusb. Can we not build some sort of bus-like device to which both the specialized and generic devices can attach which prevents opening both at the same time? Gary Duzan
