Red Hat Bugzilla – Bug 586029
LS_COLORS setup in /etc/profile.d has insufficient escaping
Last modified: 2016-02-22 07:47:48 EST
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.
Thanks for report, fixed in RAWHIDE, built as coreutils-8.5-2.fc14 .
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
coreutils-8.4-6.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/coreutils-8.4-6.fc13
coreutils-7.6-11.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/coreutils-7.6-11.fc12
coreutils-7.2-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/coreutils-7.2-8.fc11
coreutils-7.6-11.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update coreutils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/coreutils-7.6-11.fc12
coreutils-7.2-8.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update coreutils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/coreutils-7.2-8.fc11
coreutils-8.4-6.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
coreutils-7.2-8.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
coreutils-7.6-11.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.