Bug 349084

Please attach y2logs. If you are in doubt follow:

http://en.opensuse.org/Bugs/YaST

Thanks!

I think there is no need to attach anything. I had exactly the same problem with my HP C4180, it was not possible to scan. Adding the user to the "lp" group solves the problem.

In fact, I had the same problem in 10.2 when I upgraded my kernel to 2.6.22 which modifed udev rules.

I think this problem is related to a bad udev rule in 55-hpmud.rules:

seb@p64p17bicb3:/etc/udev/rules.d> cat 55-hpmud.rules
...
SYSFS{idVendor}=="03f0", OWNER="root", GROUP="lp", MODE="0664"
...

To use a scanner configured with hpaio backend (or a printer using hpjis and hp toolbox) from hplip package, the user must be in lp group. So, When an All-In-One printer or scanner is added via YaST, Yast should add users to lp group...

Another workaround is to modify the rule :

SYSFS{idVendor}=="03f0", OWNER="root", GROUP="lp", MODE="0666"

or

SYSFS{idVendor}=="03f0", OWNER="root", GROUP="users", MODE="0664"

and reboot.

This is a very well known problem and workaround, as explained in hplip website :
http://hplip.sourceforge.net/tech_docs/tarball_install.html

I think this file should be updated via a online update, due to the number of people having this problem...

An additional comment: the problem doesn't occurs when printing because cupsd is launched by root. When scanning, the hpaio backend is launched by the user with their rights. You can see your usb device with lsusb, then go to /dev/bus/usb/xxx/yyy to see rights...

Please next time remove NEEDINFO flag after adding comment that is relevant for question. You can easily do this by enabling check box "This comment provides..." below text box.

Johannes, how we can solve that?
The worst scenario is new dialog with users to add into "lp" group ...

Since HPLIP version 2.7.6 the device I/O is no longer done by
a daemon process which runs as root (therefore there have been
no permission problems with HPLIP version before 2.7.6 but on
the other hand no permission restrictions could be set with
HPLIP version before 2.7.6).

The out-of-the-box settings are sufficient for plain printing
and for scanning with a all-in-one USB device after the scanner
unit was set up with the YaST scanner tool.

For more details, see "Some special notes reagarding my packages" at

http://sourceforge.net/mailarchive/message.php?msg_name=Pine.LNX.4.64.0707040850200.22081%40nelson.suse.de

The current HPLIP version 2.7.10 in STABLE and on
http://download.opensuse.org/repositories/home:/jsmeix/
has /etc/udev/rules.d/55-hpmud.rules which has rules to set
the following permissive permissions only for HP printers
and HP all-in-one devices: OWNER="root", GROUP="lp", MODE="0666"

The problem is the read/write access for any user, see Bug 336658

By the way:

When a normal user is created by YaST, it is by default
member of the following groups: users dialout video

What do you think about to add the group "lp"
to those default groups so that normal users have
by default sufficient permissions for local printer
and local scanner access?


The biggest advantage from my point of view would be
that via traditional group-permissions it just works
as it worked all the time in the past with Linux.
In particular it just works even without the complicated
udev/HAL/hal-resmgr machinery which never ever worked
really reliably in the past.
This machinery works for 90% but on the other hand this means
that it still fails for thousands of cases and when it fails,
a normal user has no chance to fix this complicated machinery.


Reasoning regarding scanners:

Since openSUSE 10.2 all known USB scanner device files
get also the group "lp" via /etc/udev/rules.d/55-libsane.rules
see "rpm -q --changelog sane-backends":
------------------------------------------------------------------
The automatically created tools/udev/libsane.rules is changed
for openSUSE as follows: All GROUP="scanner" are replaced
by GROUP="lp"
...
The reasons are:
There is no group "scanner" in /etc/group for openSUSE.
For all-in-one devices (i.e. printer + scanner) the group
must be "lp" so that the CUPS usb backend which runs as "lp"
can send printing data to the printer unit.
It is sufficiently secure and reasonable easy to use by default
the same group "lp" for printers and scanners because both kind
of devices usually require physical user access (to get the
printed paper or to place a paper on the scanner) so that both
kind of devices should usually require the same kind of security.
------------------------------------------------------------------


Reasoning regarding CUPS:

Up to openSUSE 10.1/SLE10 we had CUPS 1.1 where we used
by default "RunAsUser" to let the cupsd run as user "lp".
Here it would be insecure to grant "lp"-permissions to
normal users because then normal users might influence
the core of the printing system and do somehow something like
http://www.cups.org/str.php?L790

Since openSUSE 10.2 we have CUPS 1.2.
Since CUPS 1.2 "RunAsUser" is no longer supported
so that we are back to the CUPS upstream default
where the cupsd runs as root but it runs all its filters
and by default also the backend as user "lp".

On the one hand this is less secure because there is
a root process which can be made accessible from the network
(since CUPS 1.2 cupsd listens by default only at "localhost"),
see "Configuration of the CUPS network servers" - "Details" at
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell

On the other hand this is more secure because filters
and backends (and whatever else runs as user "lp")
cannot influence the core of the printing system
so that since CUPS 1.2 it might be possible to
grant "lp"-permissions to normal users by default
without causing real security problems.

Of course any normal user could then send data directly
to a locally connected printer (USB and parallel port)
and circumvent a user-based restriction in the printing
system (see "-u deny:..." at "man lpadmin") but this
is perhaps no real severe security problem because
all the admin has to do is to remove this user from
the "lp" group - just like it is with our other
default groups (dialout, video).

I fully agree with idea add "lp" into default groups (/etc/default/useradd). It means that all new created user will be added into "lp" group.
Thorsten, do you agree with that?

(In reply to comment #8 from michal zugec)
> I fully agree with idea add "lp" into default groups (/etc/default/useradd). It
> means that all new created user will be added into "lp" group.
> Thorsten, do you agree with that?

I disagree. The group "lp" is there for security reasons. So that not everybody can write/read to such files/directories used by the print spooling system.

It maybe that, on a first glance, no security problem in your default installation may be visible, but to make sure, this would mean a whole audit of all code using the group "lp".

And this solution only works for local accounts, which is not necessary identical to users who are logged in local.

So resonable solution shout be this:
When you want to use "hp" backend, where will be new dialog (multiselectionbox) with users list. Then you can select users and yast will add them into "lp" group.

Johannes, do you agree with that?

10:
Good idea.

Michal,
hopefully I can fix it for most USB devices via
https://bugzilla.novell.com/show_bug.cgi?id=336658#c4

This way users who are currently locally logged in would
get read/write access via the udev/HAL/hal-resmgr machinery.

I don't know if /usr/share/hplip/data/models/models.dat
lists the USB IDs for all devices which are supported by HPLIP
so that some devices might be missing.

Additionally the udev/HAL/hal-resmgr machinery does not work
really reliably and furthermore some users may simply prefer
the traditional method via a group (see comment #7).

Therefore I think that your suggestion in comment #10
could help a lot in particular when the automatism fails.

Updated HPLIP to version 2.8.2 and submitted to STABLE
which provides an appropriate HAL fdi file
/etc/hal/fdi/policy/10osvendor/70-hpmud.fdi
so that it should work out-of-the-box at least for
those USB devices where the UDB IDs are known.

HPLIP 2.8.2 is also available for openSUSE 10.3 (and others) via
http://download.opensuse.org/repositories/home:/jsmeix/

See
https://bugzilla.novell.com/show_bug.cgi?id=336658#c5
and subsequent comments.

A note regarding my packages for openSUSE 10.3 and others:
The packages are
* only for testing
* without any guarantee or warranty
* without any support
As an extreme example, this means that if your complete computer
center crashes because of these packages, it is only your problem.
Nevertheless, I am very interested in your feedback.
Please make it obvious which package, which package version,
which hardware architecture and which openSUSE version
you are talking about, e.g.:
 "Feedback regarding the hplip[-hpijs]-2.8.2-11.2.i586 RPMs
  from http://software.opensuse.org/download/home:/jsmeix/
  for openSUSE 10.3 used on 64-bit AMD hardware."
Ideally provide also the "rpm -q --changelog sane-backends | head"
output to make it unambiguous which exact package release you have.

agree with #10. I've lost more than 15 minutes of my life searching solution for scanning as non-root and found lp group as solution.

According comment #13 marked as FIXED