Bug 438867

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. ***

Closing 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 ;-)