Arch Linux

As of: cups 1.7.3-3

Reference, from around 2012 January -
https://bugs.archlinux.org/task/26030
 FS#26030  - [cups][libusb][hplip] CUPS permissions problem

Rephrasing -

In the file "/etc/cups/cups-files.conf", if a named group in the "Group" directive is also a named group in the "SystemGroup" directive, then cupsd will run as group "nobody" instead of the group named in the "Group" directive, supposedly for security reasons. I cannot say where this is otherwise documented.

The printer devices in "/dev/", such as "/dev/parport0", are created with user "root" and group "lp". When cupsd runs as group "nobody", then cupsd will not have permission to access the printer devices, with EPERM on a 0660 root:lp dev node, AND ALL PRINTING WILL FAIL, WITH "USELESS" STATUS MESSAGES!

The Arch cups package does not install an "/etc/cups/cups-files.conf" with "colliding" Group and SystemGroup directive group names, but it also does not install any "lpadmin" group in "/etc/groups". The cups source package file "config-scripts/cups-defaults.m4" seems to check for the group names from 'GROUP_LIST="lpadmin sys system root"', including, or not including, the "lpadmin" group in the generated template file at "conf/cups-files.conf", depending whether the "lpadmin" group already exists in "/etc/group". The existence of this "lpadmin" group, though, is just a convenience for assigning authority to users, and is of no consequence otherwise.

The problem is, when re-installing the cups package, an existing file "/etc/cups/cups-files.conf" does not get over-written, nor is there any ".pacnew" file created. So, if there is an existing "cups-files.conf" file with "colliding" groups, printing is going to fail silently, and re-installing cups is not going to fix the problem.

But then, how could this "/etc/cups/cups-files.conf" ever become corrupt in the first place? Unfortunately, because this "broken" configuration is recommended at https://wiki.archlinux.org/index.php/CUPS, which has:

Change:
SystemGroup sys root
to:
SystemGroup lp root

_and_ at https://wiki.archlinux.org/index.php/KDE, which has:

Adding lp to SystemGroup allows anyone who can print to configure printers. You can, of course, add another group instead of lp.
/etc/cups/cups-files.conf
# Administrator user group...
SystemGroup sys root lp


And, why would anyone actually _read_ the CUPS wiki or the KDE wiki? Well, anyone who might initially be having a printing problem for some other reason.

And then - God help them! - because printing is _never_ going to work again, even if their original problem gets fixed. And, arguably, the CUPS error logging itself is "broken", having cupsd running as group "nobody" instead of refusing to start, and then producing a "useless" error log and "useless" printer status messages, such as "Rendering completed". Surprisingly, there is no check for device permissions in cupsd!

What to do? For starters, perhaps a big long warning message with the Arch "cups" package install. Or better, the creation of an "/etc/cups/cups-files.conf.pacnew" file. Or even better, an explicit

sed -i.pacsave -e'/SystemGroup/ {s/lp //g;s/lp$//}' /etc/cups/cups-files.conf

in a post_install script, or in the package_cups() {...} function of the cups PKGBUILD.

Perhaps this "sed" should also be applied to "/etc/cups/cupsd.conf, since the CUPS wiki recommends that the "SystemGroup" directive be added to "/etc/cups/cupsd.conf", though the "cupsd.conf" man page suggests that this directive is not allowed there. Or instead, there should be a

sed -i -e'/SystemGroup/ d' /etc/cups/cupsd.conf

also. And I may remove that section from the CUPS wiki.

Also, as a matter of course, I suggest that Arch should create an "lpadmin" group, with GID "107", as this is somewhat conventional, and may help to discourage the temptation to add the group "lp" to the "SystemGroup" directive.

This issue has been left "hanging" for at least 2 1/2 years, and who knows how many people have just "given up" with Arch because of failed printing. Please make sure that it never happens to anyone again.


James