Re: Bash security issue

[Eric Blake]

On 09/26/2014 08:22 AM, Zack Weinberg wrote:
> On September 26, 2014 3:53:53 AM EDT, lolilolicon <lolilolicon@gmail.com> 
> wrote:
>> On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh <bash@tlinx.org> wrote:
> 
>>> This behavior has been around for 20+ without it being judged "so
>> bad",
>>
>> I don't think that's a sufficient argument for "this is not so bad".
>>
>> First, the fact that the bug has existed for so long, yet fails to be
>> discovered [disclosed] until now, is proof that this feature is very
>> little used and rarely tested, not an argument for "it's not so bad".
> 
> The question in my mind is, is exporting functions a POSIX shell feature? If 
> not, perhaps it should just be scrapped altogether.

Why not read POSIX and find out for yourself?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export

export -f is not required by POSIX, so it is a shell extension.  But
people DO rely on it, so nuking it now would be a backwards incompatible
break.  I'd still like to keep it, but with a smarter implementation.
Other messages on the list have suggested smarter implementations, such
as using 'BASH_FUNC_foo()=...' instead of 'foo=() {' as the magic for
doing the export, thus eliminating the collision.

I _also_ agree that since function exports are NOT required by POSIX,
that it would be okay if we let /bin/bash continue to import functions
by default, but have bash invoked as /bin/sh refuse to do imports by
default.  If the ability to import functions becomes conditional on
argv[0], then I also suggest that bash have a 'set -o' option or 'shopt'
setting that can let the user override the default (a way to invoke
/bin/sh but with function imports, or a way to invoke /bin/bash but with
no functions).

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

signature.asc
Description: OpenPGP digital signature