Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#40937 - [cups] cups-files.conf - Group and SystemGroup directives collision causes printing to fail silently

Attached to Project: Arch Linux
Opened by James (thx1138) - Sunday, 22 June 2014, 22:11 GMT
Last edited by Andreas Radke (AndyRTR) - Monday, 16 February 2015, 16:03 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


As of: cups 1.7.3-3

Reference, from around 2012 January -
 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, which has:

SystemGroup sys root
SystemGroup lp root

_and_ at, which has:

Adding lp to SystemGroup allows anyone who can print to configure printers. You can, of course, add another group instead of lp.
# 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.

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Monday, 16 February 2015, 16:03 GMT
Reason for closing:  Upstream
Comment by Doug Newgard (Scimmia) - Sunday, 22 June 2014, 23:12 GMT
So ... this is a user configuration problem? Fix the wiki and be done with it.
Comment by James (thx1138) - Monday, 23 June 2014, 01:27 GMT
Given the cost of "sed -i.pacsave -e'/SystemGroup/ {s/lp //g;s/lp$//}' /etc/cups/cups-files.conf" in "package_cups() {...}" relative to the pain caused by any possible misconfiguration and the failure of a re-install to correct the problem, I consider "be done with it" to be callous, at best.

But yes, I'll fix the wiki.

Comment by Doug Newgard (Scimmia) - Monday, 23 June 2014, 03:13 GMT
The cost is quite high, IMO. Automatically editing the user's config files is a very bad precedence to set. There's a lot of software that does not work correctly if the user screws up the configuration, I don't see how this case is so different.
Comment by James (thx1138) - Monday, 23 June 2014, 04:59 GMT
I would suggest that it might not be fair to say "the user" exactly, as it was "the Arch Wiki" that had suggested an inappropriate change to the configuration file. So then, in a sense, should the "Arch Repository" take responsibility for past "bad advice" from the "Arch Wiki"? Are these two different entities, adversaries, one against the other? Or, are they both part of the same whole, each equally responsible for the combination which is the end user's "Arch Experience"?

But then, an install note and warning might be appropriate, rather than an automatic edit - and better than nothing at all.

Or we might instead demand that CUPS be "fixed" upstream, to refuse to start, rather than silently revert to group "nobody". That would seem to be the "proper" fix. You know Apple Inc will make a robust and reliable Linux user experience a top priority.

Comment by Andreas Radke (AndyRTR) - Friday, 03 October 2014, 10:16 GMT
There's a configure option that might help here: --with-system-groups (set default system groups for CUPS) that might help here. Can you test this with new cups
soon to be find in testing repo.
Comment by James (thx1138) - Friday, 03 October 2014, 17:55 GMT
The configure option "--with-system-groups", among other things, checks that the selected cups group, which the PKGBUILD is setting with "--with-cups-group=lp" - though that is also the default group selected by the cups configure script - is not also in some subset of the specific list "lpadmin sys system root". Obviously, "lp" is not in the list "lpadmin sys system root", so that test would be pointless.

The problem has to do with whether or not an already existing file "/etc/cups/cups-files.conf" will be overwritten. If, by whatever circumstance, the group "lp" has been added to the "SystemGroup" key in the file "/etc/cups/cups-files.conf", then printing will fail silently, and the cause is very difficult to discover. An existing configuration file, "/etc/cups/cups-files.conf", will not be overwritten by installing the Arch "cups" package. So, if there is an existing problem, then re-installing the Arch "cups" package will not fix the problem. The configure option "--with-system-groups" does NOT check the system on which the "cups" package is being installed.

I see that the new 2.0.0 package in testing will install an "/etc/cups/cups-files.conf.pacnew", but doing this will not disclose the cause of a printing failure due to the group collision.

The group "lp" is one of the default groups created by the Arch "filesystem" package, and is not added to "/etc/group" by installing the "cups" package. There is no way that the cupsd "filters/backends/helper programs" will run with User and Group settings - or that cups will run with a different "SystemGroup" setting - different from the defaults, unless these settings are manually changed in "/etc/cups/cups-files.conf" by user "root". And how would that happen? Well, in the past, that had been suggested in the Arch Wiki, as described above. The wiki has been corrected, but the damage may have already been done, nonetheless.

People who install Arch packages are more likely to have read the Arch Wiki. It is the way things happen. Now, simply, there is no proper reason to have the "lp" group in the SystemGroup in cups-files.conf on a standard Arch cups install. On the other hand, someone may have customized their installation, and have chosen some different group name for running cupsd "filters/backends/helper programs", and then have chosen to use group "lp" as the administrative group name. That would be a reason to not just blindly remove "lp" from the SystemGroup list.

But still, I think it would be polite to provide some kind of note about the past "bad advice" in the Arch CUPS and KDE Wiki entries. Certainly it would be polite to add a check for a "collision", between the "Group" and "SystemGroup" configurations in cups-files.conf, to the Arch cups package install. I also think it would be polite to create an "lpadmin" group in the Arch system, distinct from any of the "sys", "system", or "root" groups, to allow for a printer administration group in Arch.

I have submitted a bug report upstream at, suggesting that cupsd should refuse to start and say why, rather than falling back to running "filters/backends/helper programs" as group "nobody". That behavior has not changed in the new version 2.0.0 package.

Comment by Andreas Radke (AndyRTR) - Saturday, 11 October 2014, 13:56 GMT
cups-files.conf is under backup control. So if somebody changes it pacman will install a .pacnew file when updating the pkg.

I think you've run into a bad situation where cups didn't give you a useful error msg and it was caused by a bad advise in our wiki.
You've asked upstream to give a better error message and have fixed our wiki pages(?).

I won't add a note to the cups .install scriptlet. I think it's not worth. Not many users will run in your bad configuration.

Can we close this one as I see no packaging issue?
Comment by James (thx1138) - Sunday, 12 October 2014, 08:25 GMT
> You've asked upstream to give a better error message and have fixed our wiki pages(?).


> Can we close this one as I see no packaging issue?

One other suggestion - modify the default source "conf/" with a comment above the "SystemGroup" directive:

# This list cannot include the filters/backends/helper programs Group, for security reasons.

I have passed the suggestion upstream, to The added comment would not disclose the catastrophic printing failure that would result otherwise, but at least it would provide some guidance.

Comment by Andreas Radke (AndyRTR) - Tuesday, 21 October 2014, 17:48 GMT
Applied upstream fix for
Comment by James (thx1138) - Tuesday, 28 October 2014, 17:50 GMT
  • Field changed: Percent Complete (100% → 0%)
Logging does not operate as advertised. There is no group collision error message logged at the default log level of "warn", but only at log level "notice" and higher, despite the description upstream. This has been reported upstream, but there has been no response.

Either the upstream patch offered should be modified to provide logging at the default log level, or the default cupsd.conf should be modified to include the directive "LogLevel notice".
Comment by Andreas Radke (AndyRTR) - Thursday, 30 October 2014, 09:30 GMT
I'm fine to apply any changes upstream will implement. I'll have an eye on upstream STR#4495.
Comment by Andreas Radke (AndyRTR) - Sunday, 15 February 2015, 19:12 GMT
Please check with latest cups and cups-filters updates. I assume we should close this as upstream "won't fix".
Comment by James (thx1138) - Sunday, 15 February 2015, 21:52 GMT
I have filed a new bug report upstream, STR #4582 "Group and SystemGroup collision error message is not visible at default loglevel.",

Since there was clearly a confusion about which log levels were the more verbose in the patch applied, perhaps this will be corrected. Leaving this Arch bug open probably isn't going to change anything upstream though.