Bug 586957

+++ 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 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 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