Bugzilla – Bug 438867
no scanner access permissions via HAL
Last modified: 2009-01-13 10:53:16 UTC
Although the scanner is correctly setup (with yast), only can be used by root. This is the output of some commands: scanimage -L device `epson:libusb:001:002' is a Epson GT-9300 flatbed scanner ls -lha /dev/bus/usb/001/002 crw-rw-r-- 1 root lp 189, 1 oct 24 20:33 /dev/bus/usb/001/002 ('chown miquel.users /dev/bus/usb/001/002' workarounds this problem)
Please provide y2logs. More info on http://en.opensuse.org/Bugs/YaST
Created attachment 248160 [details] YaST logs IMHO this is not a yast bug, but a udev/hal rules bug.
I do not find anything in attachment #248160 [details] about the YaST scanner module so that it cannot be a bug there. Perhaps your scanner was set up full automated as described in bug #347943 so that in your case you might got the problem described in https://bugzilla.novell.com/show_bug.cgi?id=340173#c5 But this cannot be true either because according to /etc/udev/rules.d/55-libsane.rules the Epson GT-9300(UF) has the USB IDs 0x04b8:0x011b and this are also listed in /etc/udev/rules.d/56-sane-backends-autoconfig.rules but here with "sane_backend_epkowa" (i.e. using the "epkowa" driver) which does not match to "epson:libusb:001:002" in comment #0 (i.e. using the "epson" driver). It would have been nice if you described how you did set up your scanner and not let us do blind guessing via inspecting whatever files what there might have happened on your particular system. Background information: Since a longer time normal-user access for scanners is granted via the udev/HAL/hal-resmgr machinery which sets an ACL for the scanner's device file. Run lsusb to determine the current USB bus and device number and the run e.g. getfacl /dev/bus/usb/001/002 (replace bus and device number 001/002 by what is currently shown by the lsusb command for your scanner) to see if an ACL is set and if yes, which one and for which user. By default only users which are logged in directly at the computer (i.e. via console "login" or via KDM/XDM but not via remote login) get access granted via the udev/HAL/hal-resmgr machinery. It is a well known problem since this machinery is used that it does not work reliably. I am neither a USB expert nor an expert regarding udev and/or HAL and/or hal-resmgr but as far as I see, the whole machinery seems to be somewhat overcomplicated: hal-resmgr depends on HAL (and PAM) and HAL depends on udev which depends on the USB system. Therefore any issue somewhere in this stack can result whatever failure for normal users (e.g. compare bug #434540). The only thing in the YaST scanner module which makes settings for HAL is /usr/lib/YaST2/bin/test_and_set_scanner_access_permissions It writes /etc/hal/fdi/policy/10osvendor/80-scanner.fdi if the device is not already listed in /etc/hal/fdi/policy/10osvendor/70-scanner.fdi (the latter belongs to the sane-backends RPM). The YaST scanner module runs it when it set up a scanner and also via the "Other"->"Test" functionality. It does also a test whether or not it looks o.k. that the udev/HAL/hal-resmgr magic works so that normal users would get access permissions, see bug #340173. You can have a look at /usr/lib/YaST2/bin/test_and_set_scanner_access_permissions --------------------------------------------------------------------- To access the scanner as normal user, udev, HAL, and hal-resmgr are needed to grant appropriate access permissions automatically. Therefore the scanner model must be known to HAL. If the scanner is not known to HAL, a re-plug of a USB scanner should help. Otherwise a reboot should be done to restart the whole udev/HAL/hal-resmgr machinery. Check if the scanner is listed in the 'lshal' output. .. If even a reboot does not help, you could access the scanner via the 'saned' as a workaround. For this workaround choose 'scanning via network' and select the 'local host configuration'. --------------------------------------------------------------------- Usually this workaround is the only feasible solution for non-experts to get access permissions for normal users if there is an issue in the udev/HAL/hal-resmgr magic. Additionally see http://en.opensuse.org/SDB:Configuring_Scanners_from_SUSE_LINUX_9.2 --------------------------------------------------------------------- libusb + resmgr + PAM Note that the details change from version to version. Additionally there will be further enhancements (e.g. "udev", "HAL", "hal-resmgr",...). An article regarding scanner setup cannot describe all the details about USB, hotplug, udev, HAL, resmgr/hal-resmgr, PAM, and so on. Refer to the appropriate specific documentation if there are problems in one of these areas. --------------------------------------------------------------------- By the way: According to /etc/udev/rules.d/55-libsane.rules the scanner device node/dev/bus/usb/xxx/yyy should be in the "lp" group so that it should work to add the normal users which should use the scanner to the group "lp". An "automated add of normal users to the lp group" cannot be done, see bug #349084 in particular see https://bugzilla.novell.com/show_bug.cgi?id=349084#c9
Waiting for answering questions in comment #3.
Sorry for delay. After 06-Oct update, scanner works fine for users. Let me know if you're still interesed in requested info (I can reinstall Beta4 to investigate more about this bug). > It would have been nice if you described how you did > set up your scanner and not let us do blind guessing via > inspecting whatever files what there might have happened > on your particular system. Of course, I just used yast2 to configure it, ("epson" driver selected, I don't like interface provided by epowka driver). This is exactly the same process I've followed to configure this scanner since 8.0 with no problems in final versions.
Thanks, let's consider this as fixed. But if you install Beta4 or newer, please test again and reopen if it still fails.
*** Bug 444316 has been marked as a duplicate of this bug. ***
Closing bug.
*** Bug 447411 has been marked as a duplicate of this bug. ***
i reproduce in 11.1 RC 1
i new install openSuSE 11.1 RC1 and reproduce this bug
Please read Comment #3 and provide more information.
> lsusb Bus 008 Device 009: ID 04b8:012d Seiko Epson Corp. Perfection V10/V100 (GT-S600/F650) > getfacl /dev/bus/usb/008/009 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/008/009 # owner: root # group: lp user::rw- group::rw- other::r-- > /usr/lib/YaST2/bin/test_and_set_scanner_access_permissions /usr/lib/YaST2/bin/test_and_set_scanner_access_permissions: line 91: /etc/hal/fdi/policy/10osvendor/80-scanner.fdi: Permission denied >The YaST scanner module runs it when it set up a >scanner and also via the "Other"->"Test" functionality. not work. ended with an error >According to /etc/udev/rules.d/55-libsane.rules >the scanner device node/dev/bus/usb/xxx/yyy >should be in the "lp" group so that it should work >to add the normal users which should use the scanner >to the group "lp". this works. CAST is it possible to automate this process (if one user on the system than the system) or vydovat window with an explanation about the group lp when you add a scanner?
You must run /usr/lib/YaST2/bin/test_and_set_scanner_access_permissions as root (like YaST does it), otherwise line 91 in it "cat /dev/null >$HAL_LOCAL_FILE || exit 0" must of course correctly fail. Regarding "automate this process", see what I already explained in comment #3 regarding "automated add of normal users to the lp group".
*** Bug 450351 has been marked as a duplicate of this bug. ***
*** Bug 450726 has been marked as a duplicate of this bug. ***
According to comment #5 it seems it has worked at some time it has also worked for openSUSE 11.1 but now it seems to fail again because bug #450351 is for SLED 11 beta 6 and bug #450726 is for openSUSE 11.1 RC1. Therefore I reopen this report so that an expert regarding udev and/or HAL and/or hal-resmgr could have a look what goes wrong here.
For all who are in Cc of this bug: To check whether or not the udev/HAL system knows about your particular model as a "scanner", run lshal | egrep 'info\.product|scanner' and check if your particular model is shown like ----------------------------------------------------------- info.capabilities = {'scanner'} (string list) info.product = 'ACME FunScanner 1000 series' (string) resmgr.class = 'scanner' (string) ----------------------------------------------------------- If not, reboot your system and do the same check again.
On a openSUSE 11.1 beta4 system I get only ------------------------------------------------------------ info.capabilities = {'scanner'} (string list) info.product = 'CanoScan N1240U/LiDE 30' (string) ------------------------------------------------------------ i.e. the "resmgr.class = 'scanner'" line is missing. I think this could be the reason why hal-resmgr does not recognize the device as a scanner so that it also does not grant normal user access permissions for it. I set NEEDINFO from the hal-resmgr maintainer to have a look if the root cause might perhaps be in hal-resmgr?
hal-resmgr does not exist anymore. The new tool works quite similar though. It uses access_control.type now. if everything is right the output of the following two commands should be the same. $ hal-find-by-property --key access_control.type --string scanner $ hal-find-by-capability --capability scanner
well, let me guess. mv /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi /etc/hal/fdi/policy/10osvendor/90-acl-management.fdi fixes the issue?
The scanner fdi file shouldn't be in /etc/hal/fdi/policy/10osvendor/ it should go into /etc/hal/fdi/information/20thirdparty/ since it contains no policy but pure device information.
All my HAL fdi file were always in /etc/hal/fdi/policy/10osvendor/ where it worked in the past and I got never ever a note that this is the wrong place. Why the hell is this HAL stuff always all the time changing arbitrarily so that there are regression bugs so that this HAL stuff always all the time fails arbitrarily and then the HAL failures are always all the time re-assigned back to me so that I must work around all this ever-changing HAL mess? Why can this HALL mess not just work stable and reliably?
I would have to change the packages sane-backends hplip yast2-scanner But at the current state there is almost no chance to test if my changes really work well. Coolo, please decide if I should now switch all my HAL fdi files from /etc/hal/fdi/policy/10osvendor/ to /etc/hal/fdi/information/20thirdparty/ or if HAL should be changed to be backward compatible to avoid regression bugs like this one. Danny, I wonder if /etc/hal/fdi/information/20thirdparty/ is really the right place because my HAL fdi files are no third-party software for openSUSE because the above packages sane-backends, hplip, and yast2-scanner belong to the openSUSE distribution.
No directory /etc/hal/fdi/information/20thirdparty/ is provided by HAL. Should or can I create arbitrary directories in /etc/hal/fdi/information/ like /etc/hal/fdi/information/20scanner/ where the name would fit better for my case?
Taking your rather highlevel packages today is not that big problem, taking new hal unfortunately is. And I'm not sure this can be fixed with an update either. So I guess I would prefer taking these. But I'm not sure what this directory mess is all about either. there is policy vs. information and /usr/share vs. etc and 10osvendor vs. 20thirdparty. And if I understand Ludwig correctly, it's just about the order of the fdi files. What do you need to test your changes? Should be put these 3 packages in the update channel?
(In reply to comment #24 from Johannes Meixner) > Danny, > I wonder if /etc/hal/fdi/information/20thirdparty/ > is really the right place because my HAL fdi files > are no third-party software for openSUSE because > the above packages sane-backends, hplip, and > yast2-scanner belong to the openSUSE distribution. The definition of information/20thirdparty/ in the hal SPEC is: "20thirdparty - from a 3rd party, not included in hal package"
(In reply to comment #25 from Johannes Meixner) > No directory /etc/hal/fdi/information/20thirdparty/ > is provided by HAL. > Should or can I create arbitrary directories > in /etc/hal/fdi/information/ like > /etc/hal/fdi/information/20scanner/ > where the name would fit better for my case? No, you can't create /etc/hal/fdi/information/20scanner/, you have to create /usr/share/hal/fdi/information/20thirdparty as AFAICS libgphoto2 and other already do.
(In reply to comment #26 from Stephan Kulow) > But I'm not sure what this directory mess is all about either. there is policy > vs. information and /usr/share vs. etc and 10osvendor vs. 20thirdparty. And if > I understand Ludwig correctly, it's just about the order of the fdi files. The problem is that the scanner file is a file with device information. Those files should be in the /usr/share/hal/fdi/information/20thirdparty or /etc/hal/fdi/information/20thirdparty (which one doesn't matter). The files in the information directory get merged into the HAL device tree before the file in the policy directory. The policy directory contains also the ACL related fdi file. To be able to set the ACLs for scanners, the info that a device is a scanner, need to be merged before the ACL-rules file. This is why the scanner file should be in one of the two 'information' directories. Btw. I wonder why this wasn't reported earlier, since there was no change in HAL recently about this. It worked this way since we removed resmgr support and replaced it with ACL HAL support.
(In reply to comment #28 from Danny Kukawka) > No, you can't create /etc/hal/fdi/information/20scanner/, you have to create > /usr/share/hal/fdi/information/20thirdparty as AFAICS libgphoto2 and other > already do. either /usr/share/hal/fdi/information/20thirdparty or /etc/hal/fdi/information/20thirdparty (while I would prefer /usr/share/... since also all other packages install to this place).
In comment #22 you wrote that I should use /etc/hal/fdi/information/20thirdparty/ In comment #28 you write that I should use /usr/share/hal/fdi/information/20thirdparty/ A good example how the HAL stuff always all the time changes arbitrarily. Danny, Which exact directoty should I cerate and use for my HAL fdi files? Currently my HAL fdi files are hplip: /etc/hal/fdi/policy/10osvendor/70-hpmud.fdi sane-backends: /etc/hal/fdi/policy/10osvendor/70-scanner.fdi yast2-scanner: /etc/hal/fdi/policy/10osvendor/80-scanner.fdi where the entries in all three fdi files are of the form <match key="info.subsystem" string="usb_device"> <match key="usb_device.vendor_id" int="0x1a2b"> <match key="usb_device.product_id" int="0x3c4d"> <append key="info.capabilities" type="strlist">scanner</append> </match> </match> </match>
O.k. comment #30 provides the info. I will change the packages sane-backends hplip yast2-scanner to create and use /usr/share/hal/fdi/information/20thirdparty/ for their HAL fdi files.
wasn't the original reason to choose /etc because at least some of those files are generated (by yast?) at runtime?
Up to now /etc/hal/fdi/policy/10osvendor/80-scanner.fdi was created by the YaST scanner module at runtime. Now the YaST scanner module will create at runtime /usr/share/hal/fdi/information/20thirdparty/80-scanner.fdi which cannot work if /usr/ is mounted read-only. Should therefore the YaST scanner module create the directory /etc/hal/fdi/information/20thirdparty with whatever default permissions and write /etc/hal/fdi/information/20thirdparty/80-scanner.fdi or should it simply write /etc/hal/fdi/information/80-scanner.fdi because the /etc/hal/fdi/information/ directory is already provided by the hal package?
Right now I submitted hplip and sane-backends to STABLE/FACTORY. hplip.changes - Moved /etc/hal/fdi/policy/10osvendor/70-hpmud.fdi to /usr/share/hal/fdi/information/20thirdparty/70-hpmud.fdi sane-backends.changes - Moved /etc/hal/fdi/policy/10osvendor/70-scanner.fdi to /usr/share/hal/fdi/information/20thirdparty/70-scanner.fdi
(In reply to comment #34 from Johannes Meixner) > Up to now /etc/hal/fdi/policy/10osvendor/80-scanner.fdi > was created by the YaST scanner module at runtime. Wasn't aware of this. > Should therefore the YaST scanner module create the directory > /etc/hal/fdi/information/20thirdparty > with whatever default permissions and write > /etc/hal/fdi/information/20thirdparty/80-scanner.fdi Correct, write it to this directory. I guess with the same permissions as the parent directory.
Right now I submitted yast2-scanner to STABLE/FACTORY. yast2-scanner.changes - Using /usr/share/hal/fdi/information/20thirdparty/70-scanner.fdi instead of /etc/hal/fdi/policy/10osvendor/70-scanner.fdi and /etc/hal/fdi/information/20thirdparty/80-scanner.fdi instead of /etc/hal/fdi/policy/10osvendor/80-scanner.fdi (see Novell/Suse Bugzilla bnc#438867). /etc/hal/fdi/information/20thirdparty/ is created with the same usual default permissions "drwxr-xr-x root root" as the other directories in /etc/hal/fdi/ which are already provided by the hal RPM.
The new packages work on my openSUSE 11.0 workstation but not on a openSUSE 11.1 RC2 test system: udi = '/org/freedesktop/Hal/devices/usb_device_4a9_220e_noserial' info.capabilities = {'scanner'} (string list) info.linux.driver = 'usb' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_1d6b_1_0000_00_1d_0' (string) info.product = 'CanoScan N1240U/LiDE 30' (string) info.subsystem = 'usb_device' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_4a9_220e_noserial' (string) info.vendor = 'Canon, Inc.' (string) linux.device_file = '/dev/bus/usb/001/005' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'usb' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2' (string) usb_device.bus_number = 1 (0x1) (int) usb_device.can_wake_up = true (bool) usb_device.configuration_value = 1 (0x1) (int) usb_device.device_class = 255 (0xff) (int) usb_device.device_protocol = 255 (0xff) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.is_self_powered = false (bool) usb_device.linux.device_number = 5 (0x5) (int) usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-2' (string) usb_device.max_power = 500 (0x1f4) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 0 (0x0) (int) usb_device.product = 'CanoScan N1240U/LiDE 30' (string) usb_device.product_id = 8718 (0x220e) (int) usb_device.speed = 12.0 (12) (double) usb_device.vendor = 'Canon, Inc.' (string) usb_device.vendor_id = 1193 (0x4a9) (int) usb_device.version = 1.1 (1.1) (double) blackbird:~ # hal-find-by-property --key access_control.type --string scanner blackbird:~ # hal-find-by-capability --capability scanner /org/freedesktop/Hal/devices/usb_device_4a9_220e_noserial I.e. via the "--key access_control.type" it cannot find it because there is no access_control.type for this UDI. blackbird:~ # find /etc/hal/ | xargs grep 'access_control\.type' | grep scanner blackbird:~ # find /usr/share/hal/ | xargs grep 'access_control\.type' | grep scanner /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi: <merge key="access_control.type" type="string">scanner</merge> /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi: <merge key="access_control.type" type="string">scanner</merge> /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi contains --------------------------------------------------------------------------- <match key="info.capabilities" contains="usbraw"> <match key="info.capabilities" sibling_contains="scanner"> <append key="info.capabilities" type="strlist">access_control</append> --------------------------------------------------------------------------- But as far as I see <match key="info.capabilities" contains="usbraw"> is not true for scanners because it is just info.capabilities = {'scanner'} (string list) blackbird:~ # rpm -qf /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi hal-0.5.12-10.1
Even after I changed the entry for this scanner in /usr/share/hal/fdi/information/20thirdparty/70-scanner.fdi to -------------------------------------------------------------------------- <match key="usb_device.vendor_id" int="0x04a9"> <match key="usb_device.product_id" int="0x220e"> <append key="info.capabilities" type="strlist">scanner</append> <append key="info.capabilities" type="strlist">usbraw</append> </match> </match> -------------------------------------------------------------------------- and rebooted blackbird, it seems to look better in lshal: udi = '/org/freedesktop/Hal/devices/usb_device_4a9_220e_noserial' info.capabilities = {'scanner', 'usbraw'} (string list) ... Nevertheless it does not work: blackbird:~ # hal-find-by-property --key access_control.type --string scanner blackbird:~ # hal-find-by-capability --capability scanner /org/freedesktop/Hal/devices/usb_device_4a9_220e_noserial
We did various experiments on blackbird to find out what the root cause could be (without success) so that currently the HAL fdi files on blackbird are not the original ones from the current RPMs.
Fix: sed -i s/usb_device/usb/ /usr/share/hal/fdi/information/20thirdparty/70-scanner.fdi Explanation: The problem is caused by the device hierarchy. A USB device may have multiple interfaces. On current Linux kernels (it was different in the past) this is represented by a USB parent device (type usb_device) and several children (type usb) which represent the interfaces. Only the parent actually has a Linux device file (/dev/bus/usb/*/*). The current scanner fdi file adds the "scanner" property to that parent node. The ACL fdi file however expects the property in an interface node and also merges the access control properties into the interface node. That's slightly confusing as the interface doesn't actually have a device file. Since it's not possible to merge properties into the parent and to make installing an ACL possible nevertheless the ACL fdi file copies the device file property from the parent node into the interface node.
I've submitted a sane-backends package with the change. Verified with Canon Scanner.
sane-backends was checked into 11.1. Can this bug get resolved as fixed now?
Ludwig, very many thanks for the analysis and the solution! I like to state here very clearly that it was and is only Ludwig who always informed me and helped me to get this HAL mess somehow working for the current Suse Linux and openSUSE product. Again the HAL mess changed in an incompatible way so that the fdi files need to be changed too in a non-backward compatible way. For your information some snippets about the history of this nonsense of changes in HAL: Initially we had <match key="linux.subsystem" string="usb"> see https://bugzilla.novell.com/show_bug.cgi?id=142859#c0 which was changed to <match key="info.category" string="usbraw"> see https://bugzilla.novell.com/show_bug.cgi?id=142859#c10 which was changed to <match key="info.bus" string="usb_device"> see https://bugzilla.novell.com/show_bug.cgi?id=250659#c21 which was changed to <match key="info.subsystem" string="usb_device"> for openSUSE 10.3 if I remember correctly which must now according to comment #41 be changed to <match key="info.subsystem" string="usb"> and accordingly <match key="usb.vendor_id" int="0x1a2b"> <match key="usb.product_id" int="0x3c4d"> Does anybody of the readers of this bug report really expect that this HAL mess can ever work stable and reliably? At least for me it never did and I assume it will never ever work stable and reliable in the near future. The root cause of all this incredible HAL mess is of course only the totally broken way how HAL is developed (i.e. continuous incompatible changes all the time) but nevertheless as all the time in the past I accept this bug report and try again to work around the HAL mess.
Andreas, it is of course not yet fixed (see comment #24) because I must also adapt the packages hplip and yast2-scanner
(In reply to comment #44 from Johannes Meixner) > Ludwig, > very many thanks for the analysis and the solution! > > I like to state here very clearly that it was and is > only Ludwig who always informed me and helped me > to get this HAL mess somehow working for the > current Suse Linux and openSUSE product. > > Again the HAL mess changed in an incompatible way > so that the fdi files need to be changed too > in a non-backward compatible way. [...] > The root cause of all this incredible HAL mess is > of course only the totally broken way how HAL is developed > (i.e. continuous incompatible changes all the time) > but nevertheless as all the time in the past I accept > this bug report and try again to work around the HAL mess. Please don't spread FUD. As Ludwig already pointed out in comment #41, the problems are caused by changes in the linux kernel and the device hierarchy in the sysfs. There was nothing changed in the HAL usb related code since a long time. There are no "continuous incompatible changes all the time" in HAL. HAL and the SPEC is very stable and changes as e.g. from info.bus to info.subsystem where announced/known at least 6 months before the old keys where removed from HAL completely.
Thanks for the clarification in comment #46. But as far as I understand it this even proves that HAL is broken by design because its user interface (e.g. the fdi files for me as a user of the HAL system) depend on kernel-internal values which is in contradiction to http://www.kroah.com/log/linux/stable_api_nonsense.html where Greg K-H wrote ---------------------------------------------------------- Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break ... This interface is the one that users and application programmers can count on being stable. ---------------------------------------------------------- When from the user's point of view HAL works on raw kernel-internal values and when according to what Greg K-H wrote kernel-internal values must be intentionally unstable, it is obvious that also the HAL user interface (e.g. the fdi files) must be unstable which is a broken design because even the kernel provides a stable interface for the user. Here I am the user of HAL - or in other words: From the HAL point of view I am HALs customer. Probably I do not understand this all and I cannot expect to have a piece of software which lets me do hardware abstraction stuff in a stable and reliable way.
Ludwig also fixed it for hplip - very many thanks for it! Therefore I have to fix now only yast2-scanner.
Right now I submitted yast2-scanner 2.17.5 to STABLE/FACTORY. Hopefully it is fixed now - I still have to test it...
Johannes' complaint is: changes are shining through something that is supposed to be an abstraction layer. Danny explains, it is not HAL that changes. Thanks Danny! GregKH explains that kernel internal structures are not designed to be stable. My assumption is that HAL exposes those changing kernel structures. If that assumption is true, we need HAKAL, the Hardware And Kernel Abstraction Layer. What is needed to do this? Isn't HAL designed to provide most of it already? not able to also provide kernel abstraction?
It works for me with the newest packages sane-backends, hplip, and yast2-scanner. Before others can test it, make sure that you have the right newest packages installed where the RPM changelogs contain this: sane-backends: --------------------------------------------------------------------- * Wed Dec 03 2008 lnussel@suse.de - use "usb" instead of "usb_device" (bnc#438867) --------------------------------------------------------------------- hplip: --------------------------------------------------------------------- * Wed Dec 03 2008 lnussel@suse.de - use "usb" instead of "usb_device" (bnc#438867) --------------------------------------------------------------------- yast2-scanner: --------------------------------------------------------------------- * Thu Dec 04 2008 jsmeix@suse.de - V 2.17.5 - Since openSUSE 11.1 'usb_device' must be replaced by 'usb' in HAL fdi files (see Novell/Suse Bugzilla bnc#438867). Adapted test_and_set_scanner_access_permissions so that it works for openSUSE 11.1 and is still to some extent backward compatible with openSUSE 11.0. ---------------------------------------------------------------------
Comment #51 is exactly what I mean.
All I like to do is to tell the underlying system (I don't care what the underlying system actually is) that a USB device with a particular USB vendor and product ID is a "scanner" (because there is no USB device class for scanners so that there cannot be a generic rule to match for scanners). More precisely: Actually I do not care if this USB device is a "scanner" or whatever else kind of device (e.g. a all-in-one device). Actaully all I like to do is to tell the underlying system that a USB device with a particular USB vendor and product ID should be accessible for "normal users" (and I don't care what a "normal user" is according to whatever current policy of whatever current underlying system).
If the assumption that HAL exposes unstable kernel structures in its fdi files is true, it means that RPMs which provide HAL fdi files (e.g. sane-backends, hplip, yast2-scanner) must have a RPM requirement of a particular kernel version. Should I add such a RPM requirement to my packages? How should a open-source projects (e.g. SANE or HPLIP) or a third-party software vendor make RPMs which provide HAL fdi files?
*** Bug 462817 has been marked as a duplicate of this bug. ***
Is this Bugreport closed, while there are fixed packages? I'm only a DAU, but i need my scanner working sorry Bernd
Bernd, it`s closed because of duplicate. For further development refer bug 462817
I knew, that the bug 462817 is a duplicate, but is marked as resolved, with a redirection to 438867. Please reopen this one and ignore the other or help me out ;-) I have found _here_ a possible solution, but it will not work, i'm in the group 'lp' bernd@eddie:~> getfacl /dev/bus/usb/001/005 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/001/005 # owner: root # group: root user::rw- group::r-- other::r-- Bernd Repository: @System Name: sane-backends Version: 1.0.19-99.1 Name: yast2-scanner Version: 2.17.5-2.1
Hi! Exact same here. THis is aloop of two closed bugs with no solution for the problem. I was waiting for new packages as well but that might take some time longer? As far as I am concerned there is no solution for this behaviour at this point. The scanner device on my system belongs to root.root as well. I have added my user to group lp but even if I chgrp the scanner usb device to "users" my user can't see or use the scanner: as root: #lsusb: Bus 005 Device 002: ID 04b8:011f Seiko Epson Corp. Perfection 1670 #getfacl /dev/bus/usb/005/002 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/005/002 # owner: root # group: root user::rw- group::r-- other::r-- #chgrp users /dev/bus/usb/005/002 #getfacl /dev/bus/usb/005/002 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/005/002 # owner: root # group: users user::rw- group::r-- other::r-- as regular user: #sane-find-scanner -q found USB scanner (vendor=0x04b8, product=0x011f) at libusb:005:002 #scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Cheers Juergen
Bingo! @Juergen I have found the error, please enable line 858 in /etc/udev/rules.d/55-libsane.rules, then the scanner is correct identified and work as user.
bernd@eddie:~> getfacl /dev/bus/usb/001/006 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/001/006 # owner: root # group: lp user::rw- group::rw- other::r--
Hi Bernd, thanks a lot, that works. I had added myself to the "lp" group before. For the overall public though, this is not of that much help, since a regular user is not a membner of the group "lp" by default. So in the bigger picture I would consider this a workaround (which I am very grateful for!!). Wouldn't it make more sense to have the device belong to the "users" group? Then again, what do I know... Thanks again! Cheers Juergen
(In reply to comment #61) > Bus 005 Device 002: ID 04b8:011f Seiko Epson Corp. Perfection 1670 That scanner is commented out in /usr/share/hal/fdi/information/20thirdparty/70-scanner.fdi (line 2143) To discuss why that is the case (I don't know) it's best to open a new bug report (CC me) as this bug here is about the generic permission handling problem whereas you face a problem with your specific model only. Thanks!
There are lines commented out both in 55-libsane.rules and in 70-scanner.fdi for models which are actually supported because of an unexpeced side-effect of the solution of bug #439193. I reopened bug #439193. Nevertheless I wonder why the workaround which is shown by YaST (see comment #3) is not simply used: ----------------------------------------------------------- ... you could access the scanner via the 'saned' as a workaround. For this workaround choose 'scanning via network' and select the 'local host configuration'. ---------------------------------------------------------- In particular on a workstation in a trusted network environment (e.g. when the Suse firewall protects it from acceess from the external network zone / Internet) this workaround should cause no security problems.
> Nevertheless I wonder why the workaround which > is shown by YaST (see comment #3) is not simply used: > ----------------------------------------------------------- > ... you could access > the scanner via the 'saned' as a workaround. > For this workaround choose 'scanning via network' > and select the 'local host configuration'. > ---------------------------------------------------------- > In particular on a workstation in a trusted network > environment (e.g. when the Suse firewall protects it > from acceess from the external network zone / Internet) > this workaround should cause no security problems. Hi! Well, it does eat up resources to have another daemon running. Plus I personally use a scanning software that does not support network scanners (vuescan). Cheers Juergen
I wonder how much resources an idle xinetd eats up (saned is launced only when needed via the xinetd). At least my xinedt needs basically no resources when it is idle ;-)