Bug 1091566 - saned systemd support
Summary: saned systemd support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sane-backends
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 487975 1077210 (view as bug list)
Depends On: 1264980
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-25 23:04 UTC by Sandro Mani
Modified: 2017-01-08 22:05 UTC (History)
15 users (show)

Fixed In Version: sane-backends-1.0.25-3.fc25 sane-backends-1.0.25-4.fc25 sane-backends-1.0.25-4.fc24 sane-backends-1.0.25-4.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-22 04:00:58 UTC


Attachments (Terms of Use)
Proposed patch (2.32 KB, patch)
2014-04-25 23:04 UTC, Sandro Mani
no flags Details | Diff
SANE network daemon systemd support (4.98 KB, patch)
2015-02-16 11:51 UTC, poma
no flags Details | Diff
Updated saned man page (9.94 KB, text/plain)
2015-09-22 21:05 UTC, Louis Lagendijk
no flags Details

Description Sandro Mani 2014-04-25 23:04:02 UTC
Created attachment 889922 [details]
Proposed patch

Would be nice if systemd units for saned were shipped as part of the package. The units are described in [1]. Something along the lines of the attached patch. Possibly, /usr/sbin/saned should be run as user/group saned:saned (which needs to be created) instead of root.

Might be useful to document in a %doc readme: to make network scanning work
- On server, add allowed hostnames / subnets to /etc/sane.d/saned.conf
- On server, open port 6566
- On client, add server address to /etc/sane.d/net.conf

[1] http://www.sane-project.org/man/saned.8.html

Comment 1 info@kobaltwit.be 2014-10-12 18:12:28 UTC
I believe bug 1077210 is requesting what is provided in this bug. Perhaps it should be marked as a duplicate of this one.

Comment 2 info@kobaltwit.be 2014-10-12 18:20:13 UTC
On my server system (which has an working Epson Perfection 3200 Photo connected to it via usb) I have
* manually created the saned.socket and saned@.service files in /etc/systemd/system
* enabled and started saned.socket (using systemctl)
* enabled the sane service in my firewall so port 6566 is listening
* created user saned and group saned

However when I run scanimage -L on a client machine it doesn't find the scanner.

Below is the output of
$ SANE_DEBUG_NET=128 scanimage -L
[sanei_debug] Setting debug level of net to 128.
[net] sane_init: authorize != null, version_code != null
[net] sane_init: SANE net backend version 1.0.14 (AF-indep+IPv6) from sane-backends 1.0.24
[net] sane_init: Client has little endian byte order
[net] sane_init: searching for config file
[net] sane_init: trying to add 192.168.93.6
[net] add_device: adding backend 192.168.93.6
[net] add_device: backend 192.168.93.6 added
[net] sane_init: done reading config
[net] sane_init: evaluating environment variable SANE_NET_HOSTS
[net] sane_init: evaluating environment variable SANE_NET_TIMEOUT
[net] sane_init: done
[net] sane_get_devices: local_only = 0
[net] connect_dev: trying to connect to 192.168.93.6
[net] connect_dev: [0] connection succeeded (IPv4)
[net] connect_dev: sanei_w_init
[net] connect_dev: net_init (user=goudsmid, local version=1.0.3)
[net] connect_dev: argument marshalling error (Connection reset by peer)
[net] connect_dev: closing connection to 192.168.93.6
[net] sane_get_devices: ignoring failure to connect to 192.168.93.6
[net] sane_get_devices: finished (0 devices)
device `hpaio:/net/HP_Color_LaserJet_CM2320fxi_MFP?zc=hpcm2320' is a Hewlett-Packard HP_Color_LaserJet_CM2320fxi_MFP all-in-one
[net] sane_exit: exiting
[net] sane_exit: closing dev 0x7fb61448cc80, ctl=-1
[net] sane_exit: finished.

Ignore the hpaio device line for this bug. It is second scanner which is not what I'm interested in. I'm trying to find an epson2 device.

On the server side, journalctl has this in the logs:
okt 12 20:16:01 boromir.kobaltwit.lan systemd[1]: Starting Scanner Service...
okt 12 20:16:01 boromir.kobaltwit.lan systemd[1]: Started Scanner Service.
okt 12 20:16:01 boromir.kobaltwit.lan saned[5146]: saned (AF-indep+IPv6) from sane-backends 1.0.24 starting up
okt 12 20:16:01 boromir.kobaltwit.lan saned[5146]: check_host: access by remote host: localhost
okt 12 20:16:01 boromir.kobaltwit.lan saned[5146]: init: bad status=22 or procnum=-786535172
okt 12 20:16:01 boromir.kobaltwit.lan saned[5146]: saned exiting

The bad status seems to be the issue, but I have no idea where it comes from. If you need some more details, I'll happily supply them.

Both systems are running Fedora 20, 64-bit fully updated.

Comment 3 info@kobaltwit.be 2014-10-12 18:22:15 UTC
Oh, I forgot to mention that on the client I did add the server's ip address in /etc/sane.d/net.conf. That should be obvious because the client does connect to the server.

I also find the "access by remote host: localhost" quite odd. I'm not connecting from localhost as far as I know. These are two separate machines.

Comment 4 info@kobaltwit.be 2014-10-12 19:06:14 UTC
I'll just continue to add my findings as I come across them.

Interesting detail:
On the server side I have created user saned, with primary group saned. Both are system id's not ordinary user id's.

On the server side, running sane-find-scanner as a normal user results in my scanner being detected:
found USB scanner (vendor=0x04b8 [EPSON], product=0x011c [EPSON Scanner]) at libusb:001:006

If I however run this same command as user saned I get:
could not open USB device 0x04b8/0x011c at 001:006: Access denied (insufficient permissions)

The file permissions for my scanner's device file are:
ls -l /dev/bus/usb/001/006 
crw-rw-r--+ 1 root root 189, 5 12 okt 20:53 /dev/bus/usb/001/006

Changing this to 
crw-rw-rw-+ 1 root root 189, 5 12 okt 20:53 /dev/bus/usb/001/006
and now suddenly running sane-find-scanner as user saned works.

So an ordinary user clearly has access rights beyond the simple ones that my user saned doesn't have (I don't know where these are configured though). I mention this because maybe the patch attached to this bug needs some additional things to properly set up the user saned with the right permissions to scanner devices.

Unfortunately even with a world writeable device file a call to scanimage -L from the client machine still results in the exact same error (bad status=22).

Comment 5 Zbigniew Jędrzejewski-Szmek 2014-11-27 06:02:06 UTC
(In reply to info@kobaltwit.be from comment #4)
> The file permissions for my scanner's device file are:
> ls -l /dev/bus/usb/001/006 
> crw-rw-r--+ 1 root root 189, 5 12 okt 20:53 /dev/bus/usb/001/006
What does 'getfacl /dev/bus/usb/001/006' say?
By default, devices like scanners are assigned to the current user who is logged in. So most likely saned user does not have permissions.

> So an ordinary user clearly has access rights beyond the simple ones that my
> user saned doesn't have (I don't know where these are configured though).
They are managed through acls. Without knowing what they are, it's hard to say what is going on.

> Unfortunately even with a world writeable device file a call to scanimage -L
> from the client machine still results in the exact same error (bad
> status=22).
I'm guessing that 

StandardInput=null
StandardOutput=syslog

are wrong. With inetd-style socket activation the socket is passed as stdin and stdout to the process. Does it work if those lines are removed (after systemd daemon-reload && systemctl restart saned.socket).

Comment 6 info@kobaltwit.be 2014-11-29 10:24:45 UTC
This is the output of gefacl:

$ 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-
user:goudsmid:rw-
group::rw-
mask::rw-
other::r--

Note that the scanner has moved to a different usb address, but it's still the same scanner:
$ scanimage -L
device `epson2:libusb:001:005' is a Epson GT-9800 flatbed scanner

I have removed the lines 
StandardInput=null
StandardOutput=syslog

and restarted the systemd daemon and socket. It makes no difference however. The behaviour is exactly the same as before.

With the acl as above that means:
+ local user on server can access the scanner (goudsmid)
- saned user on server can't access the scanner
- remote user can't access the scanner

Changing the acl such that other gets rw access the behaviour becomes:
+ local user on server can access the scanner (goudsmid)
+ saned user on server can access the scanner
- remote user can't access the scanner

The errors generated during a remote access attempt are still exactly as in comment 2 (both server and client side).

If I can do more experiments to get this resolved I will gladly do so.

Comment 7 Zbigniew Jędrzejewski-Szmek 2014-12-03 17:29:12 UTC
*** Bug 1077210 has been marked as a duplicate of this bug. ***

Comment 8 Zbigniew Jędrzejewski-Szmek 2014-12-03 19:57:36 UTC
OK, I finally had a chance to test this.

There are two issues:

1. the .service file is borked. It should look like this:

# /usr/lib/systemd/system/saned@.service
[Unit]
Description=Scanner Service
Requires=saned.socket

[Service]
ExecStart=/usr/sbin/saned
User=saned
Group=saned
StandardInput=socket

Environment=SANE_CONFIG_DIR=/etc/sane.d
#Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128

[Install]
Also=saned.socket

(The crucial part is StandardInput=socket. Without this the socket is passed in the wrong spot.

Also imporant is the SANE_CONFIG_DIR in the environment. This part is commented out in the upstream file, but if it is not set, saned will look for the configuration file in "." and in "/etc/sane.d". The service will be started in "/", so this is not a security issue by itself, but it might trigger selinux warnings and is something better to avoid.

The other Environment line is a hint how to debug things.

And finally, other unnecessary cruft from the upstream file is removed.

Install section is added so that 'systemctl enable saned@.service' works.)

2. Permissions must be given to the saned user to access scanners.
I don't have any scanners to test, but the following should work:

# /usr/lib/udev/rules.d/70-saned.rules
ACTION=="add", ENV{libsane_matched}=="yes", GROUP="saned", MODE="0660"

(Those rules are very simplistic. Something more elaborate with a 'scanner' group could be added. I'll CC Lennart and Kay.)

Comment 9 info@kobaltwit.be 2014-12-03 21:09:25 UTC
Thanks for looking into this.

I have altered all files as you propose. The only change I made is to create 70-saned.rules in /etc/udev/rules.d instead of /usr/lib/udev/rules.d/ as I don't like creating files manually in /usr/lib.

When these changes will be packaged /usr/lib/udev/rules.d is the better choice of course.

Anyway, with your changes network scanning works again here. Thanks a lot !

Comment 10 poma 2015-02-16 11:51:46 UTC
Created attachment 992152 [details]
SANE network daemon systemd support

Tested and proven to work.
Approved by poma.

Comment 11 poma 2015-02-16 12:00:53 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
...
> #Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128

FTR, this has no effect.

However can be used with the SANE Frontends.

Comment 12 poma 2015-02-16 12:03:12 UTC
(In reply to poma from comment #11)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> ...
> > #Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128
> 
> FTR, this has no effect.

Of course, (and) without comments. :)

Comment 13 poma 2015-02-22 13:01:12 UTC
Complemented and enhanced with
https://bugzilla.redhat.com/show_bug.cgi?id=1195041

Comment 14 Jaroslav Reznik 2015-03-03 15:44:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 15 Javier Charne 2015-07-05 23:26:41 UTC
I have the same problem with Raspbian, sane 1.0.24-13, and Zbigniew solution works like a charm. 
Thanks a lot!

Comment 16 Louis Lagendijk 2015-09-21 19:18:36 UTC
Even though the solution by Zbigniew works, it is not the best solution. Saned is actually changed to support systemd socket activation. The systemd glue is activated when systemd-devel package is used. Adding a BuildRequires: systemd-devel will add the glue and make the service-file from ther manpage work. Only when the systemd glue is used, it is possible to use the debugging variables. Without the glue, saned redirects stdout and stderr to /dev/null.

I will update the upstream man-page.

I will write a new bugzilla report for adding the BuildRequires.

Comment 17 Nils Philippsen 2015-09-22 11:48:41 UTC
(In reply to Louis Lagendijk from comment #16)
> Even though the solution by Zbigniew works, it is not the best solution.
> Saned is actually changed to support systemd socket activation. The systemd
> glue is activated when systemd-devel package is used. Adding a
> BuildRequires: systemd-devel will add the glue and make the service-file
> from ther manpage work. Only when the systemd glue is used, it is possible
> to use the debugging variables. Without the glue, saned redirects stdout and
> stderr to /dev/null.
> 
> I will update the upstream man-page.
> 
> I will write a new bugzilla report for adding the BuildRequires.

This is good to know. Is there an upstream release planned, or should I attempt to backport these changes?

Comment 18 Louis Lagendijk 2015-09-22 21:03:26 UTC
Hi Nils,
Sane is in code freeze as the project is preparing for the 1.0.25 release. So you could wait if you like. I will attach the saned.man file in case you want to fix it now.

Comment 19 Louis Lagendijk 2015-09-22 21:05:28 UTC
Created attachment 1076042 [details]
Updated saned man page

Comment 20 Jan Pazdziora 2015-10-11 18:43:13 UTC
I'd like to point out that if GROUP="saned" is used in udev rule and Group=saned in the systemd service, and if the scanner is also a printer, cups will stop working. It will report the printer as with status "Waiting for printer to become available".

In the end I've used group lp for my multifunction device and that seems to preserve printing and allow scanning. Any saned systemd support should take this use case into account.

Comment 21 Henrique Martins 2015-11-15 19:34:48 UTC
I'm on fc23 fully patched, with sane and xsane downgraded to 1.0.24/fc22, as 1.0.25 fails with my scanner.

I tried to follow the instructions from this thread and when I try to connect to a systemd enabled scanner@.service I get this in syslog:
  user@NNN.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
where NNN is the UID of the user saned (in group saned and scanner, the device file is 664 root/scanner).

If I su to user saned and run /usr/sbin/saned -d, it seems to work, so I'm missing some systemd/pam configuration step.

Comment 22 Fedora End Of Life 2016-07-19 11:24:57 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 23 Brian J. Murrell 2016-07-19 12:22:55 UTC
This issue has not been fixed AFAIU.  There is nothing in this ticket to indicate such.  Reopening and setting to rawhide.

Comment 24 Jan Kurik 2016-07-26 04:50:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 25 Nils Philippsen 2016-10-07 16:16:59 UTC
*** Bug 487975 has been marked as a duplicate of this bug. ***

Comment 26 Fedora Update System 2016-10-09 10:20:44 UTC
sane-backends-1.0.25-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3da7667d60

Comment 27 Fedora Update System 2016-10-09 12:29:50 UTC
sane-backends-1.0.25-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-414ef99bc4

Comment 28 Fedora Update System 2016-10-09 13:51:01 UTC
sane-backends-1.0.25-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f828e34867

Comment 29 Fedora Update System 2016-10-10 17:42:00 UTC
sane-backends-1.0.25-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 30 Nils Philippsen 2016-10-19 09:51:32 UTC
Hmm, screwed up the name of the installed group (i.e. use "saned" not "GROUPNAME").

Comment 31 Jan Pazdziora 2016-10-19 14:23:47 UTC
It seems that sane-backends-daemon-1.0.25-4 uses Group=saned.

Was the concern from comment 20 addressed somehow as well?

Comment 32 Fedora Update System 2016-10-20 21:23:33 UTC
sane-backends-1.0.25-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3da7667d60

Comment 33 Fedora Update System 2016-10-20 21:59:14 UTC
sane-backends-1.0.25-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f828e34867

Comment 34 Fedora Update System 2016-10-20 22:57:10 UTC
sane-backends-1.0.25-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-345560d273

Comment 35 Fedora Update System 2016-10-22 04:00:58 UTC
sane-backends-1.0.25-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 36 Nils Philippsen 2016-10-27 08:44:00 UTC
(In reply to Jan Pazdziora from comment #31)
> It seems that sane-backends-daemon-1.0.25-4 uses Group=saned.
> 
> Was the concern from comment 20 addressed somehow as well?

I've looked into this a bit and here's what I found:

- Scanner device files get ACLs set on them to allow logged in users to use them, this is nothing new. I haven't found anything indicating that the group of the device files is touched.

- As it is, saned probably won't be able to access the device files right now. I guess there's a bunch of SELinux policy changes waiting to happen to make this work, too.

--> Unless saned keeps the device open after use, I don't see why this change should affect cups using it. Maybe I'm missing something?

Comment 37 Fedora Update System 2016-11-03 23:53:17 UTC
sane-backends-1.0.25-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 38 Fedora Update System 2016-11-08 22:52:28 UTC
sane-backends-1.0.25-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.