Bug 92445 - lpstat(cups) produces garbled output (depends on LANG variable)
lpstat(cups) produces garbled output (depends on LANG variable)
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: cups (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2003-10-03 06:50:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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):
cups-1.1.17-0.7
glibc-2.3.2-4.80.6

How reproducible:
always

Steps to Reproduce:

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

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


3. bug appears:
export LANG=en_US.iso885915
lpstat

    
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
LANG="en_US.iso885915"
GDM_LANG="en_US.iso885915"
SUPPORTED="en_US.iso885915:en_US:en:de_DE@euro:de_DE:de:es_ES@euro:es_ES:es"
SYSFONT="lat9-16"
SYSFONTACM="iso15"
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:
http://www.opengroup.org/onlinepubs/007904975/functions/strftime.html
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.