[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls

From: Eric Blake
Subject: Re: ls
Date: Wed, 05 Oct 2005 07:00:05 -0600
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Hash: SHA1

According to Alfred M. Szmidt on 10/4/2005 1:28 PM:
>    The command in question might be run anywhere (the documentation
>    talks about "scripts").  That would include /tmp.
> `rm *' might also be run from anywhere, hence why don't get it.

I think the point that was trying to be made is the following - if the
user does
$ cd /tmp
$ rm *

then they know exactly why files are being removed.  But if they do

$ cd /tmp
$ eval `dircolors`

then they don't expect any side effects other than to the environment
(although a craftily named file in /tmp can cause just that, by inserting
arbitrary shell code into the arguments to eval during filename globbing
expansion).  You are correct that the security bug is minor, because it is
not typical usage to run dircolors in a world-writable directory.  But we
might as well educate users to that fact, by suggesting the much safer

$ cd /tmp
$ eval "`dircolors`"

It was much easier to document the better usage of dircolors than it would
have been to revisit both dircolors and ls to come up with a new format of
LS_COLORS that does not use any unquoted shell metacharacters, and thus
would not be subject to filename globbing prior to the eval.  But had we
redone LS_COLORS, then eval `dircolors` would once again be safe without
any user intervention (although in general, it is ALWAYS wise to properly
quote the input to eval to avoid filename globbing).

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]