FS#57391 - [sane] switch to ACL-based udev.rules to avoid conflict with default printer rules

Attached to Project: Arch Linux
Opened by Arsenii (ettavolt) - Tuesday, 06 February 2018, 11:35 GMT
Last edited by David Runge (dvzrv) - Wednesday, 24 February 2021, 09:46 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
David Runge (dvzrv)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
By default sane-backends generates 49-sane.rules that change MODE to 0660 and GROUP to scanner. For MFDs 50-udev-defaults (from systemd) changes GROUP to lp. Thanks to 70-uaccess libsane_matched=yes devices are available to current 'driving' user, but scanner group can't use it.
To avoid that I propose to switch to ACL-based rules.
It could be done as patching generator Makefile.in (where is formatting help, btw?):

diff --git a/sane/trunk/PKGBUILD b/sane/trunk/PKGBUILD
index d386351..50ac38f 100644
--- a/sane/trunk/PKGBUILD
+++ b/sane/trunk/PKGBUILD
@@ -6,7 +6,7 @@

pkgname=sane
pkgver=1.0.27
-pkgrel=1
+pkgrel=2
pkgdesc="Scanner Access Now Easy"
url="http://www.sane-project.org/"
arch=('x86_64')
@@ -24,6 +24,7 @@ prepare() {
cd "${srcdir}/${pkgname}-backends-${pkgver}"
# fix http://vasks.debian.org/tracker/?func=detail&atid=410366&aid=313760&group_id=30186
patch -Np1 -i ${srcdir}/network.patch
+ sed -e 's/sane-desc -m udev /sane-desc -m udev+acl /' -i tools/Makefile.in
}

build() {

Or we can change build phase to invoke sane-desc again ourselves.

Additional info:
* sane 1.0.27-1
* systemd 236.81-1

Found this while investigating problems with https://aur.archlinux.org/packages/brscan4/
This task depends upon

Closed by  David Runge (dvzrv)
Wednesday, 24 February 2021, 09:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with sane 1.0.32-3 by a switch to udev+hwdb based setup.
Comment by Arsenii (ettavolt) - Thursday, 10 September 2020, 11:48 GMT
49-sane.rules and 50-udev-defaults are still in conflict of single-USB-connected Multi-Funcation Devices.
Comment by David Runge (dvzrv) - Tuesday, 16 February 2021, 10:54 GMT
@ettavolt: Thanks for your report!

Please give 1.0.32-2 in [testing] a try. It switched from plain udev rules to udev+hwdb.
Let us know if it fixes the issue you are seeing.

Note: For the saned@.service now the separate user/group saned is used, which gains access to USB devices via ACLs.
To my knowledge the scanner group is not relevant anymore.
Comment by Arsenii (ettavolt) - Wednesday, 24 February 2021, 09:02 GMT
Thank you for the update!

Updated to sane-1.0.32-3 and also updated brscan4. After plugging in the device, /dev/bus/usb/<busN>/<devM> had root:lp ownership with additional ACL granting access to saned group and my user.
This might be influenced by the brscan4's udev rules (they have a form of ATTR{idProduct}=="x", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes") but not much, and, actually, the main result is that there is an additional ACL for saned group.
Comment by David Runge (dvzrv) - Wednesday, 24 February 2021, 09:17 GMT
The saned group permission is added solely for the saned@.service in the sane package. :)

The scanner group is not in use anymore by the udev+hwdb setup and only the current user has access (or saned, when exposing the scanner to the network).
Comment by Arsenii (ettavolt) - Wednesday, 24 February 2021, 09:28 GMT
Sorry, I don't recall why did I need scanner group on the scanner's port back then (i.e. two years ago). Comments in brscan4 suggest nothing too. :(

saned group, being separate from lp, should work too, I guess.
Comment by David Runge (dvzrv) - Wednesday, 24 February 2021, 09:38 GMT
@ettavolt: The scanner group has been used by the plain udev rules, that sane generates during build and that we packaged.

Historically, the scanner group has been setup by our filesystem package and used for these purposes, but I think it is not really required by sane any longer.
Comment by Arsenii (ettavolt) - Wednesday, 24 February 2021, 09:42 GMT
I have no objections. :)

Even more: now the entire setup works better then I had it a couple of weeks ago, and should covers the original issue.

If I could, I'd mark this task as solved.
Comment by David Runge (dvzrv) - Wednesday, 24 February 2021, 09:46 GMT
@ettavolt: Excellent. Thanks for the feedback! :)

Loading...