On Fri, Nov 21, 2014 at 06:21:30AM +0800, konsolebox wrote:
> "eval" is not synonymous to security holes. There are many ways to sanitize
> it
> (if necessarily needed). Namerefs (declare -n in 4.3) and indirect variable
> references for example can avoid referencing invalid variable names simply by
> checking them with a pattern.
Your message deserves a longer reply than I have time for tonight, so for
now I'll just demonstrate why bash's namerefs are not useful.
Suppose you write a "library" function that takes a single argument, which
is the name of a variable. Let's call it blackbox:
blackbox() { declare -n arg=$1; printf '%s\n' "$arg"; }
It works fine, MOST of the time:
imadev:~$ blackbox LOGNAME
wooledg
But if the caller doesn't know that the word "arg" is magical, behold:
imadev:~$ blackbox arg
bash: warning: arg: circular name reference
No matter how cleverly you name your nameref, there's a CHANCE that the
caller will try to use that same name.
Once you see the error message above, you should understand that bash's
namerefs don't actually point to a variable in the caller's scope.
They don't work ANYTHING like ksh's nameref, or Tcl's upvar. They're
really just eval in disguise. As such, they inherit all the problems of
eval. For example, arbitrary undesired code execution:
imadev:~$ blackbox 'a[b=$(date)]'
bash: b=Thu Nov 20 17:33:35 EST 2014: syntax error in expression (error token
is "Nov 20 17:33:35 EST 2014")
I describe this in a bit more detail at
http://mywiki.wooledge.org/BashFAQ/048#The_problem_with_bash.27s_name_references
