Bug 988062 - CUPS LPD backend sanitize_title does not operate as documented
Summary: CUPS LPD backend sanitize_title does not operate as documented
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cups
Version: 6.6
Hardware: All
OS: All
Target Milestone: rc
: ---
Assignee: Tim Waugh
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-24 15:53 UTC by Jarett Stevens
Modified: 2015-07-23 16:27 UTC (History)
2 users (show)

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.
Clone Of:
Last Closed: 2015-07-22 06:54:39 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1346 normal SHIPPED_LIVE cups bug fix and enhancement update 2015-07-20 17:59:51 UTC
CUPS Bugs and Features 4569 None None None Never

Description Jarett Stevens 2013-07-24 15:53:29 UTC
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 11:03:39 UTC
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 13:26:43 UTC
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 23:20:42 UTC
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 06:54:39 UTC
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.