Red Hat Bugzilla – Bug 586957
LS_COLORS setup in /etc/profile.d has insufficient escaping
Last modified: 2011-07-21 08:18:19 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):
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.
Shell is slow to start if the current directory is slow to enumerate.
Shell startup time would ideally be as independent as possible of the current directory.
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 firstname.lastname@example.org on 2010-04-27 07:12:18 EDT ---
Thanks for report, fixed in RAWHIDE, built as coreutils-8.5-2.fc14 .
--- Additional comment from email@example.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:
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.
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.
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.
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.
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.