Re: REGRESSION: shellshock patch rejects valid function names

[Eric Blake]

On 09/27/2014 02:29 PM, Eric Blake wrote:
> On 09/27/2014 12:53 PM, Chet Ramey wrote:
> 
>> $ function /bin/echo () { builtin 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.
> 
> Right now, we know of no way for an attacker to force an arbitrary
> variable name - ONLY arbitrary variable contents.  So I would prefer a
> patch that allows the export/import of the exact same set of names as
> what can be used as valid function names.  Neither set should be larger
> than the other, and for back-compat purposes, at least in bash mode, the
> set needs to STILL allow for functions named 'foo::bar' or 'foo/bar'.

After thinking a bit more, I would be in favor of a patch that forbids
'/' in function names, but opposed to a patch that forbids '.'.  '/' has
special effects on PATH lookup, and it is just too confusing to think
that in bash mode, a function could override a command name containing a
slash (especially since that should NOT be possible in /bin/sh mode, for
POSIX compliance).  ksh allows '.' in function names, so we would be
needlessly incompatible if we restrict that.  As for other
non-metacharacters, I'm just fine with allowing pretty much anything
else (',', ':', '@', '-'), as none of them have special rules on shell
behavior.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature