[Top][All Lists]

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

Re: Issues with exported functions

From: Eric Blake
Subject: Re: Issues with exported functions
Date: Thu, 25 Sep 2014 09:23:45 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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