cupsctl cannot read cupsd.conf and corrupts the file when changing config #5744
Comments
|
Just would like to say that I’ve run into this issue. It was a bit surprising. |
|
@tillkamppeter I'm not able to reproduce in Fedora 32, where cups 2.3.1 is shipped. cupsctl --debug-logging works for me. |
|
Hi there, I'm trying to reproduce this bug. I grabbed master of cups and did a basic make && make test; once the test is built, it will leave a private cupsd running with a script - in my case /private/tmp/cups-steve/runcups, which can be used to target it. cupsctl in that context produces the expected output. This is both on a recent Mac OS and Debian 4.9.168 x86_64 What system reproduces are you seeing this on? Does it reproduce for you with this "isolated" cupsd? |
|
I have observed the problem on Ubuntu Focal Fossa (20.04 under development) with the current GIT snapshot of CUPS. |
1. Fix conversion of PPD option choice names to IPP attributes When I create a CUPS queue with a PPD file with choice names "Tray-1", "Tray-2", ... in the InputSlot option CUPS translates these names to double-dashed IPP attribute names: "tray--1", "tray--2", ... in the "media-source" attribute, both when passing a job to the printer with the IPP backend, making the printer ignore the tray choice, and also when answering a get-printer-attributes IPP request from a client. This happens when in the PPD a dash is followed by a digit, as the pwg_unppdize_name() function in cups/ppd-cache.c inserts a dash whenever a non-digit is followed by a digit in the PPD name. As IPP attribute names generally never have double-dashes and also no dashes in the beginning or the end of the name, I have modified the pwg_unppdize_name() function appropriately. Upstream bug: apple/cups#5740 Debian bug: https://bugs.debian.org/949315 2. Fix scheduler's cupsd.conf load (triggered by cupsctl and web interface) When running it without arguments it is supposed to read the local CUPS's cupsd.conf and show a summary of the setting. in CUPS 2.3.1 it shows a mess with a lot of HTML inside and this is due to the fact that when loading the file via HTTP using the /admin/cups/cupsd.conf path the scheduler calls the admin.cgi program which returns the admin front page of the web admin interface. cupsctl then tries to interpret that as the config file and displays garbage. Even worse is if you run cupsctl with command line argument (one of the five switches or a key=value pair) to change a setting. It seems to load cupsd.conf again and gets again the HTML code of the web interface page. cupsctl tries to interpret this again, producing garbage, adds the user-supplied setting and writes all this back into cupsd.conf. Then it tries to restart the scheduler which fails due to the broken config file. The problem is that in the file scheduler/client.conf, in the function get_file() the URI from the client is at first checked whether it begins with "/admin/" and in this case the CGI program admin.cgi is responsible. Only after that the check for "/admin/conf/cupsd.conf" comes and is never reached. I have changed the order now appropriately and this way cupsctl works again. Note that the problem only occurs if the web interface is active and the cupsctl command is issued by a non-root user. This is a regression caused by issue Upstream bug: apple/cups#5744
|
@tillkamppeter I believe we fixed this in OpenPrinting CUPS. If not, please re-file this over there, thanks! |
|
This is fixed. I had fixed it in a distro patch and it seems to have gotten incorporated into OP CUPS with all the distro patches. |
From CUPS 2.3.1 on cupsctl is broken.
When running it without arguments it is supposed to read the local CUPS's cupsd.conf and show a summary of the setting. in CUPS 2.3.1 it shows a mess with a lot of HTML inside and this is due to the fact that when loading the file via HTTP using the /admin/cups/cupsd.conf path the scheduler calls the admin.cgi program which returns the admin front page of the web admin interface. cupsctl then tries to interpret that as the config file and displays garbage.
Even worse is if you run cupsctl with command line argument (one of the five switches or a key=value pair) to change a setting. It seems to load cupsd.conf again and gets again the HTML code of the web interface page. cupsctl tries to interpret this again, producing garbage, adds the user-supplied setting and writes all this back into cupsd.conf. Then it tries to restart the scheduler which fails due to the broken config file.
The problem is that in the file scheduler/client.conf, in the function get_file() the URI from the client is at first checked whether it begins with "/admin/" and in this case the CGI program admin.cgi is responsible. Only after that the check for "/admin/conf/cupsd.conf" comes and is never reached.
I have changed the order now appropriately and this way cupsctl works again.
Note that the problem only occurs if the web interface is active and the cupsctl command is issued by a non-root user.
This is a regression caused by issue #5652.
Patch to fix the problem is attached:
fix-scheduler-cupsd.conf-load.patch.txt
The text was updated successfully, but these errors were encountered: