Re: Bash security issue

[Nick Bowler]

On 2014-09-26 08:51 -0600, Eric Blake wrote:
> On 09/26/2014 08:45 AM, Nick Bowler wrote:
> > On 2014-09-25 15:08 -0700, Linda Walsh wrote:
> >> Eric Blake wrote:
> >>> Where I'm coming from is that in portable shell programming, you _can't_
> >>> assign a value to f()=...  The fact that portable programs are now
> >>> slammed with the notion that some values cannot be portably assigned
> >>> to a variable...
> >> ---
> >> slammed?  It's not like this is new...
> > [...]
> >> As other have said:
> >>
> >>     «Geir Hauge wrote: Bash has had this feature since "forever"»
> >>
> >>     «Pierre Gaston wrote:  How many instance have you found since the
> >>      introduction of this feature more than 20 years ago?»
> > 
> > Since I don't use bash it's not surprising that I've never noticed any
> > problem.
> > 
> > But I try to write scripts that are portable to bash, because I know
> > that many people do use it.  What I learned from this is that bog-
> > standard assignments like this:
> > 
> >    foo=$1; export foo
> > 
> > are not portable to bash, and may fail to work correctly depending on
> > the user's input.
> 
> They are not portable to broken bash.  But the argument in these threads
> is that bash's implementation of function exports should be changed so
> that _fixed_ bash will once again be POSIX compliant and let this
> bog-standard assignment work regardless of contents.  If Chet accepts
> Florian's patch [1] to change function exports to use BASH_FUNC_foo()=
> instead of foo= (which is what Red Hat is already using in their fixes
> pushed today), then this POSIX compliance bug in broken bash will be
> avoided.

I agree.  This sounds like a simple and effective solution.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)