Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)
On 10/10/14, 10:55 AM, Stephane Chazelas wrote: 2014-10-10 10:17:40 -0400, Chet Ramey: [...] bash -c '(( XDG_VTNR 7 )) That allows arbitrary code execution (and can't easily be fixed without breaking backward compatibility). Try with export XDG_VTNR='a[$(echo2 vulnerable)]'. Sure, and that's documented, intended, and not unique. [...] Is it really intended and documented that cmdsubst be performed there? Yes, all of the word expansions are performed on an array subscript. AFAICT, it's not useful and not consistent. a='$(echo 1+1)' bash -c 'echo $((a))' Doesn't work. So why would these work a='b[$(echo 1+1)]' bash -c 'echo $((a)) Or a='$(echo 1+1)' bash -c 'echo $((b[a]))' then? Where is it documented that variable, arithmetic, command, tilde and process substitution are performed in array subscripts in indirectly evaluated arithmetic expressions? You have to put it together. A variable need not be expanded before arithmetic evaluation, so the evaluator expands, for instance, a bare `a' to `b[$(echo 1+1)]'. When a variable is expanded, its value is treated as an expression to be evaluated. An array subscript -- for an indexed array -- is an arithmetic expression. All tokens in an arithmetic expression, including an array subscript, undergo variable expansion, word splitting, and quote removal. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [RFC] Logically composable variant of errexit
On 10/10/14, 5:26 AM, Andreas Grünbacher wrote:
2014-10-10 3:29 GMT+02:00 Chet Ramey chet.ra...@case.edu:
What does logically composable mean in this context?
I would like the hypothetical errfail option to:
* Behave like errexit at the top level (outside of functions).
* Be inherited by functions, subshells, and command substitution.
* Inside functions, it should trigger like errexit would outside of
functions, no matter how the function is called.
It should return instead of exiting, though.
So you want executing shell functions -- and only executing functions --
to change the entire scope of errexit. For example, you want functions to
return on an error, presumably with a non-zero return status. However,
this is not compatible with your first point, which says that at the top
level, it would behave like errexit. Since functions are simple commands,
a function returning a non-zero status would ordinarily cause the `top
level' to behave as if any other simple command failed.
With errexit, you get vastly different results from functions depending
on how the functions are called, for example,
Sure, because functions are simple commands. They are subject to the same
conditions as any other simple command.
foo() {
echo foo: top
false
echo foo: bottom
}
set -o errexit
# bottom of foo reached:
if foo; then
echo success # reached
fi
# bottom of foo not reached:
foo
With errfail, foo:bottom and success would not be reached.
Command substitutions would continue to behave as basic commands
do with respect to control flow: inside functions, a failure would cause
the function to return; outside of functions, the script would exit.
Hmm...but command substitutions are not themselves commands: they are a
word expansion. The fact that an assignment statement returns the status
of a command substitution in the absence of a command is a very special
case. Given that special case, though, there is already a way to do
what you want, unless you want
some-command with some $(arguments) here
to exit the shell if $(arguments) ends up returning a non-zero status.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
expansions upon arithmetic evaluation in array subscripts
2014-10-13 09:02:38 -0400, Chet Ramey: [...] You have to put it together. A variable need not be expanded before arithmetic evaluation, so the evaluator expands, for instance, a bare `a' to `b[$(echo 1+1)]'. When a variable is expanded, its value is treated as an expression to be evaluated. An array subscript -- for an indexed array -- is an arithmetic expression. All tokens in an arithmetic expression, including an array subscript, undergo variable expansion, word splitting, and quote removal. [...] Thanks. I'm still confused though. In b=2 a='1 + $b' echo $((a)) a is expanded and the expansion is also evaluated as an arithmetic expression, so why isn't $b expanded there? Note that it's not only variable expansion, it's also tilde (even though ~ is also an arithmetic operator) expansion. $ HOME=1 a='b[~]' bash -c 'b=(1 2 3); echo $((a))' 2 That means for instance that foo=-1 echo $((a[~foo])) won't work on systems where there's a foo user. It's also command substitution obviously. Not process substitution though contrary to what I previously said (which would have been a bigger problem for things like: arr[x(a+b) ? x : y] ) I wasn't aware of word splitting. I didn't think that could apply given that we're not in list context (splitting into several words doesn't make sense where). That makes it a difference with other shells. $ a='1-+1' c='b[$a]' bash -c 'b=(1 2 3); IFS=-; echo $((c))' 3 $ a='1-+1' c='b[$a]' ksh -c 'b=(1 2 3); IFS=-; echo $((c))' 1 Again, I'd say it's not very consistent and doesn't make much sense: $ a='1-+1' c='b[$a]' bash -c 'b=(1 2 3); IFS=-; echo $((c))' 3 $ a='1-+1' bash -c 'b=(1 2 3); IFS=-; echo $((b[$a]))' 1 Why splitting (and joinging with space?) in the first case and not the second? -- Stephane
Re: patchset to optionally disable function exports
On 9/25/14, 4:37 PM, David Galos wrote: I understand that some people might find function exports useful, but there is also some utility in being able to turn it off. I will probably include some variant of this in the next release of bash. Thanks for the report and patches. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
