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
