Bug 92445 - lpstat(cups) produces garbled output (depends on LANG variable)
lpstat(cups) produces garbled output (depends on LANG variable)
Product: Red Hat Linux
Classification: Retired
Component: cups (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-06-06 07:06 EDT by Peter Englmaier
Modified: 2007-04-18 12:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-03 06:50:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Englmaier 2003-06-06 07:06:54 EDT
Description of problem:
I believe this has nothing to do with cups, but it happens with the cups lpstat
command. Most likely it is related to glibc.

lpstat normally produces output like:
$ lpstat
lp3-18                  ppe               1024   Fri Jun  6 11:55:05 2003

When the variable LANG is set to en_US.iso885915, it produces garbled 
output in the date field and some strings are copied to the input buffer.
When I press return, this strings is executed as a command. Possible
security problem? The bug
appears in bash and sash. It seems not to happen in csh,tcsh, but these
have different environment setup.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

put printer 'lp' on hold and print some file:
disable lp
touch test.txt
lpr -Plp test.txt

2. bug doesn't appear:
export LANG=
export LANG=de_DE

3. bug appears:
export LANG=en_US.iso885915

Actual results:
$ lpstat
lp3-18                  ppe               1024   ¨š
$ LANG= lpstat
lp3-18                  ppe               1024   Fri Jun  6 11:55:05 2003

Expected results:

Additional info:
$ cat /etc/sysconfig/i18n
Comment 1 Tim Waugh 2003-06-18 04:41:03 EDT
I don't see this here.

As far as I can tell, lpstat is calling strftime(..., "%c", ...) for this.  Care
to use ltrace to verify that?
Comment 2 Peter Englmaier 2003-06-20 11:16:26 EDT
The output of ltrace is:

....[cut out leading part]...
localtime(0xbfffd77c)                             = 0x4213aca0
snprintf("lp3-82", 255, "%s-%d", "lp3", 82)       = 6
strftime("\250\232\005\b", 32, "%c", 0x4213aca0)  = 0
printf("%-23s %-13s %8d   %s\n", "lp3-82", "ppe", 1024, "\250\232\005\b") = 54
ippDelete(0x0805ba00, 0xbfffd7a0, 0x0805be80, 1024, 0xbfffd780) = 0
lp3-82                  ppe               1024   ¨<9A>^E^H
+++ exited (status 0) +++

BTW, I just found out that the Problem disappears  if TZ is set. 
The text copied  to the command line is -always- 'xterm', so when you press
return only another xterm pops up, i.e. there is no security risk.
Comment 3 Jakub Jelinek 2003-10-03 06:43:26 EDT
strftime in the ltrace returned 0. That means according to:
that the size of the buffer was too small and the buffer content is undefined.
Perhaps cups doesn't check strftime's return value?
Comment 4 Tim Waugh 2003-10-03 06:50:22 EDT
This was fixed in 1.1.19-9 in rawhide.

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