Saned group is missing permissions to access scanners via udev-acl

[Martin Owens]

The udev rules for scanners now allow everyone to scan by using acl control, the problem with this control is that it doesn't allow the saned user/group to access the scanner.

This prevents scanners from being scared over the network, unless they're hp scanners. There are some workarounds for instance:

http://blog.crox.net/archives/64-Scanner-permissions-in-Ubuntu-Karmic-udev-libusb-saned-problem-with-udev-acl.html

Which when tested didn't work for Maverick. But I think this should be fixed in the saned rules/acl rules somehow to guarantee the saned user/group can access scanners.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: sane (not installed)
ProcVersionSignature: Ubuntu 2.6.32-25.44-generic 2.6.32.21+drm33.7
Uname: Linux 2.6.32-25-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Fri Apr 29 16:45:20 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: sane-frontends

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Psy[H[] (vovik-wfa)]

Stumbled on this, and I'm SHOCKED.
Why, in a name of what the group mechanism was removed?
It was simple, stable, efficient, KISS, unix-way of accessing scanners!
Please restore the group mechanism! You broke something that worked like fine-tuned clockwork. It is the recommended way in SANE manual.

[Psy[H[] (vovik-wfa)]

Tried to restore by adding
/etc/udev/rules.d/90-sane-group-fix.rules
with following content:
ENV{libsane_matched}=="yes", GROUP="saned"

but device still gets in root group

is there a way to add group support without breaking something?

[Martin Owens (doctormo)]

Psy, In maverick I added:

ENV{libsane_matched}=="yes", GROUP="saned"

to /lib/udev/rules.d/70-acl.rules

But I also think that saned should be fixed to use the acl instead of looking for the saned group, it's weird how any users are allowed to access it but saned is not.

[Psy[H[] (vovik-wfa)]

it is weird how group management is being cut out from the system.
maybe ACL's and consolekit are good tools, but why dismantle unix groups? They work.

[Psy[H[] (vovik-wfa)]

adding group rule to 70-acl.rules does not work also

[Martin Owens (doctormo)]

You need to add the rule to the middle of the file, where it does the acl flag.

[Psy[H[] (vovik-wfa)]

i've inserted it right after that line.

OK, let's change the approach. Where are acl parameters? Maybe there is a way to add acl item with 'scanner' group using new method?

[Martin Owens (doctormo)]

It's encoded in a C program the acl problem called from that rules file. I think it's changing the owner back to root. There's a program to list the extended permissions on a file. the program is super stupid about being able to expand what groups and users can access a file.

[Psy[H[] (vovik-wfa)]

Is there any sense in using a super-stupid program, that practically does nothing, instead of convenient unix-groups that can do whatever you ask?

[Psy[H[] (vovik-wfa)]

If I understand correctly, current behavior is to dynamically grant scanner access to currently active user via consolekit.
1. this is overengineering
2. this is useless overengineering. What the point in doing that? Just to use consolekit for something?

Why not just put new regular users to scanner group by default?

[Psy[H[] (vovik-wfa)]

_replacing_
ENV{libsane_matched}=="yes", TAG+="udev-acl"
with
ENV{libsane_matched}=="yes", GROUP="saned"
 works

[Psy[H[] (vovik-wfa)]

As files in /lib/udev/rules.d will be updated by package upgrades, the correct workaround is to put corrected 70-udev-acl.rules to /etc/udev/rules.d/ (file of the same name will override the rule in /lib...)

[Martin Owens (doctormo)]

The correct fix is to change udev-acl to accept a group param to make sure it goes into the right group, or give the saned user special privileges.

[Psy[H[] (vovik-wfa)]

Today udev package was upgraded in Archlinux. Change notification states that it now uses upstream udev-acl rules for managing devices.
Funny thing: both standard group assignment AND udev-acl mechanisms work simultaneously. I've just tested.

$ getfacl /dev/bus/usb/008/002
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/008/002
# owner: root
# group: scanner
user::rw-
user:psycho:rw-
group::rw-
mask::rw-
other::r--

What's wrong with ubuntu's udev?

[Psy[H[] (vovik-wfa)]

There is the line in libsane rules:
ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"
But it does not work

I've placed a test line nearby
ENV{libsane_matched}=="yes", RUN+="/usr/bin/touch /tmp/udev-scanner-test"
it works.

acl package is installed, /bin/setfacl exist, /usr/bin/setfacl points to /bin/setfacl.

[Psy[H[] (vovik-wfa)]

Hm...
If I place GROUP= definition in libsane rules (instead or alongside setfacl rule), it works.

Other devices in ubuntu, such as disk, cdrom, audio, video are handled by both standard GROUP= rules and udev-acl.

$ getfacl /dev/sda1
getfacl: Removing leading '/' from absolute path names
# file: dev/sda1
# owner: root
# group: disk
user::rw-
group::rw-
other::---

I would suggest fixing /lib/udev/rules.d by replacing:
ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"
with
ENV{libsane_matched}=="yes", GROUP="scanner"
and restoring scanner group

That way both group and acl rules will work for scanners.

[Psy[H[] (vovik-wfa)]

problem is in /lib/udev/rules.d/40-libsane.rules which resides in libsane package.

[Martin Owens (doctormo)]

So does setfacl work, have you tried to run the command and see what happens and why it fails?

[Psy[H[] (vovik-wfa)]

OK, tested setfacl rule...
it does not work because there is no scanner group.
But it does work with existing groups.

also 40-libsane.rules is THE ONLY udev rule that contains setfacl command. Everything else in the system assigns groups with GROUP=

Anyway, libsane package should create a group to work with.

It also must depend on acl package for setfacl variant to work. But it sounds like overengineering.

I'm currently have only Oneiric systems, so I can not say on which release 'setfacl' rule appeared in libsane.rules. But there were no such line in 10.10

[Martin Owens (doctormo)]

OK sounds like we've found the problem with the package. We need to still create the scanner group in the libsane package. We should get this information to the debian/ubuntu package maintainer.

[Martin Owens (doctormo)]

Psy, on my oneiric machine, I have a scanner group, I also have a saned group. I believe the problem is between these two groups. I've emailed the maintainers to ask for advice.

[Psy[H[] (vovik-wfa)]

i've tried reconfiguring and reinstalling libsane and sane-utils packages.
scanner group was not created

[Matti Viljanen (direc85)]

This is still an issue in 12.04.

In order to have scanbuttond (and saned, should I need it in the future) run as user saned, I had to add udev rule:

99-libsane.rules
ENV{libsane_matched}=="yes", OWNER="saned", GROUP="scanner"

Before the rule:
# file: dev/bus/usb/001/005
# owner: root
# group: root
user::rw-
group::rw-
group:scanner:rw-
mask::rw-
other::r--

After the rule:
# file: dev/bus/usb/001/006
# owner: saned
# group: scanner
user::rw-
group::rw-
group:scanner:rw-
mask::rw-
other::r--

Now scanbuttond works as expected.

I'm tired of banging my head against this now that it works, so could please somebody test the following things:
- Does the group 'saned' exist after fresh install and after installing 'sane'
- Does the group 'scanner' exist after fresh install and after installing 'sane'
- Does the user 'saned' belong to group 'scanner'

Footnote: Should user 'saned' also belong to group 'lp' in order to print using scanbuttond's buttonpressed.sh script?

[Tom Schutter (t-schutter)]

I am running 12.04 (Precise). On my machine, the problem turned out to be that the saned user was not part of the scanner group. So the simple solution for me was to add the saned user to the scanner group with the command:

sudo adduser saned scanner

Diagnosing the problem was made difficult by the fact that the group of the device file is root. On my machine, sane-find-scanner reveals that my scanner is at libusb:003:002. There is no "normal" indication that the scanner group can read the device:

$ ls -l /dev/bus/usb/003/002
crw-rw-r--+ 1 root root 189, 257 Oct 13 09:02 /dev/bus/usb/003/002

You must use the getfacl command to determine that the scanner group has read permission:

$ getfacl /dev/bus/usb/003/002
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/002
# owner: root
# group: root
user::rw-
user:tom:rw-
group::rw-
group:scanner:rw-
mask::rw-
other::r--

We can see that the scanner group was granted read permission via setfacl:

$ grep setfacl /lib/udev/rules.d/40-libsane.rules
ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"

[Rolf Leggewie (r0lf)]

does this ever occur in trusty or later?

[Rolf Leggewie (r0lf)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!