cups-files.conf - Group and SystemGroup directives collision causes printing to fail silently #4495
Comments
|
CUPS.org User: mike James, This is logged, so it isn't completely silent. As for not starting cupsd, that would probably be equally opaque, but it should probably respect the "FatalErrors config" setting. |
|
CUPS.org User: thx1138 Desperately examining log files in /var/log/cups/, I could not find any log message that would disclose the cause of this indefinitely "pending" print job. So "logging" a print failure with an "opaque" message is "useless" to both the user and to the administrator. There was no "permission failure" error message. "Pending" is NOT a good word to use to indicate "utterly and permanently failing to print because group 'nobody' has no permission to access the printer". Yes, not "completely silent". But please provide a more appropriate mechanism for this group name collision. My thought in not starting cupsd would be to not start and to provide a very explicit error message saying why cupsd is not starting - something like "For security, the back-end programs run-as group cannot also be a member of the SystemGroup in file /etc/cups-files.conf." In the greater scheme of things, actually starting cupsd, in a mode in which it will not print, is actually much much worse than not starting, simply because, by starting, there is an implication that it is performing, or will perform, some useful function, which is both false and misleading. By cupsd starting, the Group/SystemGroup misconfiguration becomes "undiscoverable". Ultimately, this is not a minor bug, for anyone foolish enough to have stumbled into it. If cupsd had instead totally crashed, at least the administrator would have known there was a problem. But printing will fail permanently, nonetheless, with no explanation. James |
|
CUPS.org User: thx1138 One other suggestion - modify the default source "conf/cups-files.conf.in" with a comment above the "SystemGroup": This list cannot include the filters/backends/helper programs Group, for security reasons.James |
|
CUPS.org User: mike The message you should see is: It is a Notice level message and should show up with the default log level of "warn". The attached patch adds a warning to the config file and honors the FatalErrors directive (exiting cupsd if the config is not valid). |
|
"str4495.patch": Index: conf/cups-files.conf.in--- conf/cups-files.conf.in (revision 12220) Administrator user group, used to match @System in cupsd.conf policy rules...+# This cannot contain the Group value for security reasons... Index: scheduler/conf.c--- scheduler/conf.c (revision 12220)
|
|
"str4495-log-level.patch": --- scheduler/conf.c 2014-10-30 20:33:59.889546682 -0600
|
|
CUPS.org User: thx1138 Thanks Michael. I tested this and it works. And the added comment in cups-files.conf is very helpful. Could the error message show up in the system log also, in addition to the cups error log? In that way, running "sudo systemctl status org.cups.cupsd.service" will directly display the reason for cupsd terminating. |
|
CUPS.org User: mike We don't log in multiple locations, however there is a bug tracking enhanced logging that would allow you to get the info that way (all the time). |
|
CUPS.org User: thx1138 I just tried setting "LogLevel debug2" in cupsd.conf, with an intentional group collision in cups-files.conf, but I don't see the error message in the system log. Is there something else that enables enhanced logging? |
|
CUPS.org User: mike The log message will appear in the /var/log/cups/error_log, unless you've changed the ErrorLog directive to point someplace else. |
|
CUPS.org User: thx1138 Thanks - sorry - found it. Setting "ErrorLog syslog" in cups-files.conf. Testing this, with systemd journald, I see no cupsd entries at log level warn. There are cupsd entries only for the higher log levels: notice info debug debug2. Similarly, using "ErrorLog /var/log/cups/error_log", there is no error message in error_log until log level notice. That is not what you wanted. Sorry - I only tested this at log level debug before. Also, there is some odd interaction with "systemctl status org.cups.cupsd.service". The journald log entries show normally, but the "systemctl status ..." displayed journald log only shows some arbitrary subset of the cupsd log entries. At log level notice, it shows the cupsd error message, which is the only cupsd entry, so that works. At log level info, it shows the "Listening to ..." entries, but no others, and does not show the error message, which is the final entry. At log level debug, the output is the same as for log level info. At log level debug2, the "systemctl -n status ..." output is a larger and larger portion of these cupsd entries as n gets bigger, but never the last few lines, which includes the error message as the final entry. Is that some issue with systemd? Or is there some kind of cupsd "log flagging" that could influence the "systemctl status" display? The systemctl man page says about the status command "followed by most recent log data from the journal", so something is not right there. |
|
CUPS.org User: mike Logging via syslog puts you into a mode where you need to change the syslog configuration to control the log level and what is visible/not (LogLevel in cupsd.conf just controls what we send to the syslog, after that it is up to syslogd or journald to determine what log entries are kept...) Similarly, the journal is really just showing the last N entries, and we don't have control over what shows up there. But STR #4474 is tracking changes to provide enhanced logging, and perhaps there is a way to inform systemd of the current state of cupsd beyond whether it is running or not... I suggest you continue any discussion of your logging requirements there... |
|
CUPS.org User: thx1138 Did you want the cupsd error message at the default log level "warn" or only at log level "notice" and higher? There is no group collision error message shown at log level "warn". |
|
CUPS.org User: thx1138 Here is a patch for scheduler/conf.c against the current git branch-2.0 which changes the log level from CUPSD_LOG_NOTICE to CUPSD_LOG_WARN for the Group and SystemGroup collision. |
Version: 2.0.0
CUPS.org User: thx1138
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 "filters/backends/helper programs" will run as group "nobody" instead of the group named in the "Group" directive, for security reasons.
If the printer devices in "/dev/", such as "/dev/parport0", are created with user "root" and group "lp", then, when cupsd runs as group "nobody", cupsd will not have permission to access the printer devices, AND ALL PRINTING WILL FAIL, WITH "USELESS" STATUS MESSAGES!
Falling back to group "nobody" is a very inappropriate solution to a security problem, exactly because the net result is a silent printing failure, and the cause is very difficult to discover. Really, this can be very exasperating.
Instead, cupsd should simply fail to start at all, with an explicit error message that the Group group is in the list of SystemGroup groups, and that this is not allowed.
James
The text was updated successfully, but these errors were encountered: