Bug 1091566

I believe bug 1077210 is requesting what is provided in this bug. Perhaps it should be marked as a duplicate of this one.

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.

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.

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).

(In reply to info 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).

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.

*** Bug 1077210 has been marked as a duplicate of this bug. ***

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.)

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 !

Created attachment 992152 [details]
SANE network daemon systemd support

Tested and proven to work.
Approved by poma.

(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.

(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. :)

Complemented and enhanced with
https://bugzilla.redhat.com/show_bug.cgi?id=1195041

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

I have the same problem with Raspbian, sane 1.0.24-13, and Zbigniew solution works like a charm. 
Thanks a lot!

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.

(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?

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.

Created attachment 1076042 [details]
Updated saned man page

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.

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: 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.

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.

This issue has not been fixed AFAIU.  There is nothing in this ticket to indicate such.  Reopening and setting to rawhide.

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

*** Bug 487975 has been marked as a duplicate of this bug. ***

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

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

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

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.

Hmm, screwed up the name of the installed group (i.e. use "saned" not "GROUPNAME").

It seems that sane-backends-daemon-1.0.25-4 uses Group=saned.

Was the concern from comment 20 addressed somehow as well?

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

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

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

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.

(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?

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.

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.