Re: Issues with exported functions

[Eric Blake]

On 09/25/2014 07:03 AM, Chet Ramey wrote:
> On 9/25/14, 4:52 AM, Gabriel Corona wrote:
>> Hello,
>>
>> As the interface is not specified, would it make sense to:
>>
>>  * add a prefix (use BASH_FUNCTION_foo instead of foo for exported
>>    function foo);

I'd much rather prefer the use of an invalid shell name (such as
f()=...) than a valid shell name (BASH_FUNCTION_foo=()...).

>>
>>  * still expand the variable if it matches the 'exported function'
>>    pattern.
> 
> Yes, that's one of the approaches under consideration.  It raises the
> bar for abuse by requiring that an attacker be able to create environment
> variables with arbitrary names as well as values.  It is not,
> unfortunately, backwards compatible.

It's not backwards compatible, but who cares?  The only time it matters
is if you are mixing old and new bash ON THE SAME SYSTEM, and TRYING TO
EXPORT FUNCTIONS BETWEEN THEM.  But the old bash behavior is so bad that
people are unlikely to want to have both shells installed.  As long as
you have only new bash installed, then all parent-child relationships
will both understand the SAME interpretation of 'f()=...' in the
environment as a way to export shell functions, and leave 'f=() {...' as
a raw normal variable and avoid intruding on the user's possible string
space.

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

signature.asc
Description: OpenPGP digital signature