Bug 586957 - LS_COLORS setup in /etc/profile.d has insufficient escaping
LS_COLORS setup in /etc/profile.d has insufficient escaping
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
5.6
All Linux
low Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
:
Depends On: 586029
Blocks: 586949
  Show dependency treegraph
 
Reported: 2010-04-28 11:02 EDT by Ondrej Vasik
Modified: 2011-07-21 08:18 EDT (History)
5 users (show)

See Also:
Fixed In Version: coreutils-5.97-28.el5
Doc Type: Bug Fix
Doc Text:
Previously, certain scripts parsing the LS_COLORS environment variable used insufficient escaping, resulting in slow shell start-up in directories with too many files. This bug has been fixed and the shell start-up time is now more independent of the current directory.
Story Points: ---
Clone Of: 586029
Environment:
Last Closed: 2011-07-21 06:36:38 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 Ondrej Vasik 2010-04-28 11:02:00 EDT
+++ This bug was initially created as a clone of Bug #586029 +++

Description of problem:

During shell startup, an unnecessary directory scan of the current directory is performed, which can cause a noticeable delay if the current directory is large or slow to access (such as over nfs).

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

coreutils-7.2-7.fc11.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. cd to a large directory (I noticed this in /usr/share/man/man3)
2. echo exit | script -c "strace -f bash 2>&1" /dev/stdout | less
3. search for blocks of consecutive getdents calls. Two instances of scanning /etc/profile.d can be ignored. After these the next instance is a scan of the current directory.
  
Actual results:

Shell is slow to start if the current directory is slow to enumerate.

Expected results:

Shell startup time would ideally be as independent as possible of the current directory.

Additional info:

For most shells, /etc/profile.d/colorls.sh is executed. Line 33 is:

    eval `dircolors --sh "$COLORS" 2>/dev/null`

dircolors produces a shell snippet that defines and exports LS_COLORS, which itself contains a list of glob patterns and their corresponding colour mappings. So the above expands to, roughly:

    eval LS_COLORS='......:*.tgz=01;31:....'; export LS_COLORS

The single quoting which normally supressed globbing in that line is interpreted in within the command line of the eval, what finally gets executed by the eval has had the quotes stripped so undergoes pathname expansion. Unless you're in a very weird directory when this happens, this will fail and leave the string unmodified, but not before scanning the current directory "just in case".

(Attempts to make the expansion do anything more interesting usually fail with ENAMETOOLONG, but I suppose if you could get a user to launch a shell in a chosen directory in a filesystem with an unfeasibly large name limit containing a file with a chosen name, you could inject arbitrary strings into the user's LS_COLORS variable. For example if the user's home directory is mounted on such a filesystem and an attacker can create, or persuade the user to create, such a file there. That could then perhaps be used to hide certain files (including the one that triggered this), or inject arbitrary escape sequences into ls output attempting to exploit terminal emulator bugs.)

To preserve the quotes into the eval the arguments must be double-quotes:

    eval "`dircolors --sh "$COLORS" 2>/dev/null`"

A similar problem probably exists in /etc/profile.d/colorls.csh (for C-shell type shells) but my csh-fu is too weak to know for sure.

--- Additional comment from ovasik@redhat.com on 2010-04-27 07:12:18 EDT ---

Thanks for report, fixed in RAWHIDE, built as coreutils-8.5-2.fc14 .

--- Additional comment from fedora-triage-list@redhat.com on 2010-04-28 08:03:39 EDT ---


This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 RHEL Product and Program Management 2010-08-09 14:18:16 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 unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 4 RHEL Product and Program Management 2011-01-11 15:15:02 EST
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 unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 5 RHEL Product and Program Management 2011-01-11 17:23:08 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 10 Tomas Capek 2011-07-13 08:14:46 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, certain scripts parsing the LS_COLORS environment variable used insufficient escaping, resulting in slow shell start-up in directories with too many files. This bug has been  fixed and the shell start-up time is now more independent of the current directory.
Comment 11 errata-xmlrpc 2011-07-21 06:36:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1074.html
Comment 12 errata-xmlrpc 2011-07-21 08:18:19 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1074.html

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