Re: REGRESSION: shellshock patch rejects valid function names

[Chet Ramey]

On 9/26/14, 4:17 PM, Eric Blake wrote:

> At any rate, this seems like an inadvertent regression that could be
> patched; are you willing to propose such a patch?  The gist of the
> matter is that the code base must use the same decision on what forms a
> valid function name as it does in deciding what exported non-variable
> names in the environment can be reinstated as functions.  I'm fairly
> certain that Chet will be reasonable about this, and after the worst
> fires are put out, we can revisit this.

It wasn't inadvertent, but it is not intended to be permanent.  Here is
the long explanation, cut from a discussion earlier today on a different
mailing list:

The original set of patches (bash43-025 and its siblings) tightened the
restrictions on allowable imported function names, forcing them to be
shell identifiers.  The shell itself, when not in posix mode, allows
virtually any character that is not a shell metacharacter to appear in
a function name (that's basically the difference between an identifier
and a word in shell-grammar-speak).  This results in the ability to
define functions like this:

$ function /bin/echo () { builtin echo whoops; }

and have this happen:

$ /bin/echo
whoops

along with exporting these functions and importing them without complaint.

This is obviously bad, and I removed the ability to do this in the first
patch in the event that someone figured out an easy way to remotely
specify an arbitrary variable name before we implemnted something to stop
it.

The problem is that it's too restrictive.  There are folks who have taken
advantage of this flexibility to define, use, and export functions like

STD::what::does::this::do

which are no longer allowed.  This is a pretty bad break with backwards
compatibility.

So what's your opinion on the appropriate set of restrictions? This is a
question that goes farther than what a particular shell will import,
since I'm going to align the restrictions on what functions a shell will
import from the environment with what functions that shell will let a
user define.  That means that a posix-mode shell will require imported
functions to be valid identifiers, but a non-posix mode shell will allow
words.  The original check that was in bash-4.3 does this.  What additional
checks should there be? I can see starting with rejecting function names
that can be confused with pathnames.

(And I'm not interested in rehashing decisions that were made 25 years
ago, and I am completely aware that this "violates" Posix.  That's why it
doesn't do this in posix mode.)

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/