The installed/supplied ${FILESDIR}/66-saned.rules has an invalid path for setfacl and the group it sets is also incorrect. current rule: ENV{libsane_matched}=="yes", ENV{DEVNAME}!="", RUN+="/usr/bin/setfacl -m g:saned:rw $env{DEVNAME}" "RUN" should be: RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}" using saned & xinetd a usb scanner is unavailable to network clients because the saned application invoked from xinetd drops privileges to saned:scanner and the usb device node is root:usb owned with no write permissions for other. Reproducible: Always
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3865b4531959596959b487d84fd862e2aac4999f commit 3865b4531959596959b487d84fd862e2aac4999f Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-04 04:17:27 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-04 04:18:58 +0000 media-gfx/sane-backends: fix configure w/ clang 16; fix service file & udev - Fix configure with Clang 16 - Fix saned_at.service user name (scanner->saned, as scanner is the group) - Fix path to setfacl in udev rule (previous one assumed /usr merge) - Fix group name in udev rule (saned->scanner) - Call udev_reload in pkg_post{rm,inst} Closes: https://bugs.gentoo.org/876772 Closes: https://bugs.gentoo.org/859619 Closes: https://bugs.gentoo.org/849590 Signed-off-by: Sam James <sam@gentoo.org> media-gfx/sane-backends/files/66-saned.rules-r1 | 2 + .../sane-backends-1.1.1-configure-clang16.patch | 43 +++ .../files/sane-backends-1.1.1-musl.patch | 34 ++ media-gfx/sane-backends/files/saned_at.service-r1 | 18 + .../sane-backends/sane-backends-1.1.1-r5.ebuild | 376 +++++++++++++++++++++ 5 files changed, 473 insertions(+)
Thanks!
media-gfx/sane-backends-1.1.1-r7 and media-gfx/sane-backends-1.1.1-r10 have both reverted to using the older 66-saned.rules with incorrect¹ setfacl path and incorrect group. ¹ while it can be argued that the path is correct for systemd systems that have been migrated to merged-usr (i.e. "-split-usr" set in profile) any other system will have the wrong path. My understanding is that in Gentoo systemd with merged-usr has symlinks from /bin -> /usr/bin so using the path in 66-saned.rules-r1 will result in correct operation in both cases.
(In reply to Bill Prendergast from comment #3) PS: even after considering the path between split-usr and merged-usr the group is still wrong.
(In reply to Bill Prendergast from comment #3) > media-gfx/sane-backends-1.1.1-r7 and media-gfx/sane-backends-1.1.1-r10 have > both reverted to using the older 66-saned.rules with incorrect¹ setfacl path > and incorrect group. > > ¹ while it can be argued that the path is correct for systemd systems that > have been migrated to merged-usr (i.e. "-split-usr" set in profile) any > other system will have the wrong path. My understanding is that in Gentoo > systemd with merged-usr has symlinks from /bin -> /usr/bin so using the > path in 66-saned.rules-r1 will result in correct operation in both cases. To be clear, the change yesterday was unintentional and just an error in script. Are you re-explaining why the original change was useful or are you pointing out an issue in 66-saned.rules-r1? (It seems like the former, but I want to check.)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bbb466bb667bb9b0af11e24619c58fe336838e65 commit bbb466bb667bb9b0af11e24619c58fe336838e65 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-18 07:05:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-18 07:07:07 +0000 media-gfx/sane-backends: fix udev rule again Previous change wasn't intentional -- the script used for the libtiff revbumps got it wrong. Fixes: 70e19cb29c796c97f89a870ee991374857014d82 Closes: https://bugs.gentoo.org/876772 Signed-off-by: Sam James <sam@gentoo.org> .../sane-backends/sane-backends-1.1.1-r10.ebuild | 367 --------------------- ....1-r7.ebuild => sane-backends-1.1.1-r11.ebuild} | 0 2 files changed, 367 deletions(-)
(In reply to Sam James from comment #5) > > To be clear, the change yesterday was unintentional and just an error in > script. Are you re-explaining why the original change was useful or are you > pointing out an issue in 66-saned.rules-r1? > > (It seems like the former, but I want to check.) I had not searched through the commit history to determine the specifics of the change, and so was unaware that it may have been accidental automation mishap.
(In reply to Bill Prendergast from comment #7) > (In reply to Sam James from comment #5) > > > > To be clear, the change yesterday was unintentional and just an error in > > script. Are you re-explaining why the original change was useful or are you > > pointing out an issue in 66-saned.rules-r1? > > > > (It seems like the former, but I want to check.) > > I had not searched through the commit history to determine the specifics of > the change, and so was unaware that it may have been accidental automation > mishap. No worries, thanks! I just wanted to make sure I wasn't missing something with the fixed version. Cheers for your patience.
