Bug 988062 - CUPS LPD backend sanitize_title does not operate as documented
CUPS LPD backend sanitize_title does not operate as documented
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cups (Show other bugs)
All All
low Severity low
: rc
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2013-07-24 11:53 EDT by Jarett Stevens
Modified: 2015-07-23 12:27 EDT (History)
2 users (show)

See Also:
Fixed In Version: cups-1.4.2-69.el6
Doc Type: Bug Fix
Doc Text:
Documentation for the operation of the CUPS Line Printer Daemon back-end "sanitize_title" option has been amended and now describes the option clearly.
Story Points: ---
Clone Of:
Last Closed: 2015-07-22 02:54:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 4569 None None None Never

  None (edit)
Description Jarett Stevens 2013-07-24 11:53:29 EDT
Description of problem:

CUPs help indicates the following (from doc/help/network.html): 
sanitize_title=no - Specifies that the job title string should not be restricted to ASCII characters.
sanitize_title=yes - Specifies that the job title string should be restricted to ASCII characters.

The default is sanitize_title=yes.  The above indicates that NON-ASCII characters are restricted (replaced with "_"), but in reality all characters that are not ASCII alphanumeric or space are restricted (for example: ?, $, =).

The relevant section of backend/lpd.c (~line 480):

  if (sanitize_title)
    * Sanitize the title string so that we don't cause problems on
    * the remote end...

    char *ptr;

    for (ptr = title; *ptr; ptr ++)
      if (!isalnum(*ptr & 255) && !isspace(*ptr & 255))
    *ptr = '_';

Either the code or the documentation should be corrected since the documented operation is misleading.

Possible patch to operate as documented:
--- backend/lpd.c.orig  2013-07-24 10:15:51.102608626 -0500
+++ backend/lpd.c       2013-07-24 10:16:17.495839026 -0500
@@ -493,7 +493,7 @@
     char *ptr;
     for (ptr = title; *ptr; ptr ++)
-      if (!isalnum(*ptr & 255) && !isspace(*ptr & 255))
+      if (!isprint(*ptr & 255))
        *ptr = '_';

Version-Release number of selected component (if applicable):
specific: cups-1.4.2-50.el6_4.4.x86_64
All versions of cups from 1.4.2-current are affected.

How reproducible:

Steps to Reproduce:
1. Set "Loglevel debug" in /etc/cups/cups.conf
2. Restart CUPS
3. Print test document to any LPD network printer: lpr -Ptestprinter -J TEST=TEST ./test.txt

Actual results:
In debug output (/var/log/cups/error_log): "JTEST_TEST"

Expected results:
In debug output (/var/log/cups/error_log): "JTEST=TEST"

Additional info:
Work around by setting sanitize_title=no in LPD printer URI if the remote end can handle it.
Comment 2 Tim Waugh 2013-07-25 07:03:39 EDT
The code went in several years before the documentation (2003, 2007), so I'm inclined to think it's the documentation that's wrong.
Comment 3 Jarett Stevens 2013-07-25 09:26:43 EDT
That could certainly be the case.  If it's updated to indicate what actually happens, that would be sufficient.  There may be legacy equipment that doesn't handle non-alphanumeric characters in the document title/job name/etc, which could explain why it operates as it does.  In my case I had a legacy platform that required the NAME=VALUE to be passed as part of the LPD communication, and I was lead astray thinking that only non-ASCII characters were stripped. (This was one of several items I was trying to match up when troubleshooting and comparing legacy-to-legacy vs RHEL6-to-legacy LPD communications.)
Comment 4 RHEL Product and Program Management 2013-10-13 19:20:42 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 7 errata-xmlrpc 2015-07-22 02:54:39 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.