[Printing-architecture] CUPS systemd issues

Michael Sweet msweet at apple.com
Wed Oct 15 19:27:05 UTC 2014


All,

Posting here to get the widest possible audience, as systemd support in CUPS is relatively new (at least for upstream) and we have a few serious bugs reported against CUPS 2.0 on CUPS.org...


STR #4491: CUPS mis-categorizes v1.::127.0.0.1 as not being localhost
    http://www.cups.org/str.php?L4491

Systemd is mapping IPv4 addresses to the 6to4 address space, so instead of getting separate v4 and v6 listeners we have two v6 listeners. This bug MUST be fixed in systemd - treating 6to4 addresses as equivalent to an IPv4 address is a major security hole that we closed during the development of CUPS 1.2, and we will not be opening that hole just to support systemd.  However, if we change the socket file to not list any IP socket listeners (option 1 below) that fix will no longer be required (at least not by CUPS - I still think you'll want to fix it for other IP services that have adopted systemd)


STR #4497: "Port 631" binds to localhost only (systemd regression)
    http://www.cups.org/str.php/L4497

The Linux kernel has a "feature" that prevents a process from listening on the "any" address at the same time as a specific address for the same port. Thus, if systemd is listening on port 631 for connections to localhost, cupsd cannot also create a listener for the "any" address on port 631 when printer sharing is enabled.

Short of the Linux kernel being updated to support what *BSD has supported for years, I see two ways for us to "fix" this issue:

1. Remove the localhost listeners from the org.cups.cupsd.socket file and just run-on-demand based on local domain socket IO. When the web interface is enabled we can disable the on-demand mode, just as we do when printer sharing is enabled or when there are pending jobs.

2. Install two socket files (org.cups.cupsd-sharing.socket and org.cups.cupsd-no-sharing.socket) and enable/disable the correct file based on the current cupsd.conf configuration. An alternative would be to rewrite the socket file based on the cupsd.conf configuration, however there are already users that object to CUPS writing to /etc...

I'm leaning towards option #1.

Thoughts?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20141015/046975c6/attachment.p7s>


More information about the Printing-architecture mailing list