Bug 141480 - bogus "test" in path confuses colorls.csh
bogus "test" in path confuses colorls.csh
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: coreutils (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-01 09:53 EST by Marvin Solomon
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-18 12:40:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
colorls.csh (764 bytes, text/plain)
2004-12-01 09:59 EST, Tim Waugh
no flags Details
fixed version of /etc/profile.d/colorls.csh (792 bytes, text/plain)
2005-01-16 12:32 EST, Marvin Solomon
no flags Details
fixed version of /etc/profile.d/colorls.sh (724 bytes, text/plain)
2005-01-16 12:35 EST, Marvin Solomon
no flags Details
fixed version of /etc/profile.d/less.csh (500 bytes, text/plain)
2005-01-16 12:35 EST, Marvin Solomon
no flags Details
fixed version of /etc/profile.d/less.sh (463 bytes, text/plain)
2005-01-16 12:36 EST, Marvin Solomon
no flags Details

  None (edit)
Description Marvin Solomon 2004-12-01 09:53:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Description of problem:
The script /etc/profile.d/colorls.csh contains lines like this:
    test -f ~/.dircolors && set COLORS=~/.dircolors
If you have an executable named "test" in your path before /usr/bin/test,
it gets executed, producing bizzare results.  By default, tcsh sources
/etc/csh.cshrc, which sources all of /etc/profile.d/*.csh, so any attempt
to run a shell runs into it.  Moreover, with the default environment
setting

    LESSOPEN=|/usr/bin/lesspipe.sh %s

any attempt to run less ultimately tries to run a shell which runs afoul
of the bogus test.


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

How reproducible:
Always

Steps to Reproduce:

    1. Create an executable "test" containing
    #!/bin/sh
    echo ======test "$@"
    sleep 3
    echo ======done
2. Put this file somewhere early in your path.  For example,
    put it in "." if "." is at the start of your path (yes, 
    I know that's naughty, but that's not the point).
3. Type "tcsh"


Actual Results:  ======test -e /etc/DIR_COLORS.xterm-color
======done
======test -f /home/solomon/.dircolors
======done
======test -f ~/.dircolors.xterm-color
... etc ...

Expected Results:  A new tcsh should have started.

Additional info:

The script colorls.csh should be rewritten to use "/usr/bin/test" or
"[" instead of "test".
Comment 1 Tim Waugh 2004-12-01 09:59:58 EST
Created attachment 107715 [details]
colorls.csh

Please try this replacement.
Comment 2 Marvin Solomon 2005-01-16 12:05:32 EST
This version replaces
    test COND && STMT
with
    if ( COND ) STMT
which fixes the original reported problem with "test".

HOWEVER:

1.  I can't verify whether it breaks the original purpose of 
this script, since I don't use the "color ls" feature.

2.  While it fixes the problem with "test", it leaves a 
similar problem with "dircolors" and introduces a new one
with "sed".  If there is an executable version of either sed 
or dircolors earlier in your path than /bin/sed or
/usr/bin/dircolors, you will see the same bizzare results.

IMHO, scripts in /etc/profile.d should only use shell
builtins and absolute paths.  A good example is
/etc/profile/lang.csh.  A bad example is
/etc/profile/less.csh, which uses relative pathnames for
"cut" and "tr".

I should point out that this problem has serious security 
implications.

I will attach to this bug report what I consider to be the
correct fixes to these files.  I note that your version
replaces a call to egrep with somewhat different logic using
sed instead of egrep.  Since I don't understand the reason
for this change, my version will leave egrep alone (except
for specifying an absolute path).
Comment 3 Marvin Solomon 2005-01-16 12:32:05 EST
Created attachment 109842 [details]
fixed version of /etc/profile.d/colorls.csh
Comment 4 Marvin Solomon 2005-01-16 12:35:21 EST
Created attachment 109843 [details]
fixed version of /etc/profile.d/colorls.sh
Comment 5 Marvin Solomon 2005-01-16 12:35:56 EST
Created attachment 109844 [details]
fixed version of /etc/profile.d/less.csh
Comment 6 Marvin Solomon 2005-01-16 12:36:17 EST
Created attachment 109845 [details]
fixed version of /etc/profile.d/less.sh
Comment 7 Tim Waugh 2005-01-18 12:40:31 EST
Not all of the above files belong to the bash package.  However:

  Do not put "." first in your PATH.
Comment 8 Marvin Solomon 2005-01-18 14:31:30 EST
> Not all of the above files belong to the bash package. 
No, none of them do.  The colorls.* files are in coreutils-4.5.3-26 and the
less.* files in less-378-11.  They are all part of Red Hat Enterprise Linux.

> However:
> Do not put "." first in your PATH.
Yes, as I said before, I know that one isn't supposed to do that.  Nonetheless
many people do and placing a stumbling block like this in files that executed
by everybody without warning and before the user's own dot files is just
asking for trouble.  Tell me, what's wrong with the fixes I proposed?
Comment 9 Tim Waugh 2005-01-19 04:41:02 EST
The fixes give the illusion of security where there is none.  If you put "."
first in your PATH, you must use full pathnames for every command you type, and
so must every shell script you ever use.

The only answer is not to put "." first in your PATH.
Comment 10 Marvin Solomon 2005-01-19 14:06:49 EST
I don't agree that an incomplete fix is worse than none, but I see your
point.  Thanks for responding.

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