Bug 860481

Summary:	Printer sharing stopped working after installing security fix for bnc#857372
Product:	[openSUSE] openSUSE 13.1	Reporter:	Petr Tesařík <ptesarik>
Component:	Security	Assignee:	Security Team bot <security-team>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P1 - Urgent	CC:	amach, forgotten_j8w14dsa0P, jsmeix, msvec, sebastian.kuhne
Version:	Final
Target Milestone:	---
Hardware:	All
OS:	openSUSE 13.1
Whiteboard:
Found By:	L3	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Petr Tesařík 2014-01-25 14:06:52 UTC

The fix for bnc 857372 broke printer announcements on my box. I ran strace on the cupsd process and got:

baltazar:~ # strace -p 3739
Process 3739 attached
epoll_wait(8, {}, 4096, 21000)          = 0
sendto(7, "829056 5 ipp://192.168.84.69:631"..., 233, 0, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("192.168.84.255")}, 16) = -1 ENETUNREACH (Network is unreachable)
epoll_wait(8,

Then I did the following:

1. I copied /usr/lib/systemd/system/cups.socket to
   /etc/systemd/system/cups.socket
2. I reverted cups-0002-systemd-listen-only-on-localhost-for-socket-activation.patch on this copy
3. I restarted cups and cups.socket
4. Printer announcement works again.

This is the output from strace after the change:

baltazar:~ # strace -p 3810
Process 3810 attached
epoll_wait(3, {}, 4096, 16000)          = 0
sendto(10, "829056 5 ipp://192.168.84.69:631"..., 233, 0, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("192.168.84.255")}, 16) = 233
epoll_wait(3, {{EPOLLIN, {u32=3217210880, u64=140693460925952}}}, 4096, 31000) = 1
recvfrom(10, "829056 5 ipp://192.168.84.69:631"..., 1540, 0, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("192.168.84.69")}, [16]) = 233
epoll_wait(3, 

Alternatively, I was also able to get this to work by stopping the cups.socket systemd service completely. This has the added benefit of stopping these messages in /var/log/cups/error_log:

E [25/Jan/2014:14:43:36 +0100] Unable to bind socket for address 0.0.0.0:631 - Address already in use.
E [25/Jan/2014:14:43:36 +0100] Unable to bind socket for address [v1.::]:631 - Address already in use.

So, it seems somehow related to bnc 857778, but I'm not sure because that one was reported before the last cups maintenance update was released.

Honestly, I don't fully understand the handling of cups sockets under systemd, but breaking existing features sounds wrong to me. You may say it's a configuration issue, but please consider the following questions:

1. How does the configuration of cups.socket correspond to the web interface,
   particularly http://localhost:631/admin/ option
     [ ] Share printers connected to this system
   ?

2. If you suggest that cups.socket is not needed on a typical system, then
   why is it enabled by default?

Comment 1 Forgotten User j8w14dsa0P 2014-01-25 17:20:30 UTC

I fixed it by changing /usr/lib/systemd/system/cups.socket from

[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=127.0.0.1:631
ListenStream=[::1]:631
ListenDatagram=127.0.0.1:631
ListenDatagram=[::1]:631
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target

to:

[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=127.0.0.1:631
ListenDatagram=127.0.0.1:631
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target

Those two lines were added after updating cups from 1.5.4-12.1.3 to 1.5.4-12.4.1

Comment 2 Petr Tesařík 2014-01-26 13:42:29 UTC

I was also able to get it working with the following configuration:

[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
BindIPv6Only=ipv6-only

[Install]
WantedBy=sockets.target


Given that cups creates the TCP and UDP sockets on startup, I'm unsure how things are supposed to work if they are created by systemd instead.

Comment 3 Sebastian Kuhne 2014-01-26 19:48:58 UTC

Hi Christoph,

first of all, I have experienced the same issue you observed.

I tried your fix and changed /usr/lib/systemd/system/cups.socket according to your proposal (1:1). Unfortunately, this was not successful. The printer is not shared in the network.

Hope we get a regular fix soon.

Best regards
Sebastian

(In reply to comment #1)
> I fixed it by changing /usr/lib/systemd/system/cups.socket from
> 
> [Unit]
> Description=CUPS Printing Service Sockets
> 
> [Socket]
> ListenStream=/var/run/cups/cups.sock
> ListenStream=127.0.0.1:631
> ListenStream=[::1]:631
> ListenDatagram=127.0.0.1:631
> ListenDatagram=[::1]:631
> BindIPv6Only=ipv6-only
> 
> [Install]
> WantedBy=sockets.target
> 
> to:
> 
> [Unit]
> Description=CUPS Printing Service Sockets
> 
> [Socket]
> ListenStream=/var/run/cups/cups.sock
> ListenStream=127.0.0.1:631
> ListenDatagram=127.0.0.1:631
> BindIPv6Only=ipv6-only
> 
> [Install]
> WantedBy=sockets.target
> 
> Those two lines were added after updating cups from 1.5.4-12.1.3 to
> 1.5.4-12.4.1

Comment 4 Johannes Meixner 2014-01-28 11:43:39 UTC

cups-0002-systemd-listen-only-on-localhost-for-socket-activation.patch
is the "right" security fix for bnc#857372 according to what
was discusseed there, see in particular
https://bugzilla.novell.com/show_bug.cgi?id=857372#c18

I think it is the intended purpose that with this fix
it must no longer "just work" without explicit settings
by the admin to make the cupsd accessible via outer network
because otherwise it would be insecure.

I think the security people together with the systemd people
should try to find a secure and usable way how normal users
can use the cupsd, see also bnc#860331

I think the current situation is a dilemma between security
and "make it all just work out of the box" that I cannot solve, see
https://bugzilla.novell.com/show_bug.cgi?id=857372#c19

According to
https://bugzilla.novell.com/show_bug.cgi?id=860331#c1
I also change the bugzilla component to "Security" here.

Comment 5 Johannes Meixner 2014-01-28 16:09:49 UTC

I reopened bnc#857372 and assigned it to me.

I will try to clean up the mess - regardless that my
knowledge regarding systemd unit files is very limited.

For the full story see bnc#857372 ... ;-)

*** This bug has been marked as a duplicate of bug 857372 ***