text: On 09/28/2014 10:31 AM, Ángel González wrote: > David patch doesn't address the fact that variables and functions are in different namespaces, though. That is, if I do 'export f=1; f(){ echo 2;}; export -f f', then what would "$f" be in the child shell? With just your patch, but not the fix for separate namespaces of 4.3.27, you are still trying to pass two separate 'f=...' environment variables, with unspecified results, and risk the child getting 'echo "$f"' to see the unexpected "() { echo 2; }' instead of the expected "1". Your approach of lazy parsing may still have benefits, but it is not a middle ground, in that we MUST have separate namespaces (patch 27), and once we have separate namespaces, your patch is no longer adding security, just optimization. > >> John Haxby recently posted that "A friend of mine said this could be a >> vulnerability gift that keeps on giving." >> (). Bash will be a continuous rich >> source of system vulnerabilities until it STOPS automatically parsing normal >> environment variables; all other shells just pass them through! I've >> turned off several websites I control because I have *no* confidence that >> the current official bash patches actually stop anyone, and I am >> deliberately *not* buying products online today for the same reason. I >> suspect others have done the same. I think it's important that bash change >> its semantics so that it "obviously has absolutely no problems of this kind". > > That's exactly what my patch does, although it wouldn't be transparent > if used inside bash (eg. echo $FUNC), as opposed of usage by its > children (wouldn't be hard to change, though). I consider it an important design goal to ensure that ALL exported variables cannot be corrupted no matter what their contents are. We aren't quite there yet (due to the issues of 'function a=b () {:;} corrupting the variable named BASH_FUNC_a even after patch 27 is applied). But your own admission that $FUNC may be corrupted is an argument against your patch in isolation. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library
  signature.asc
  Description: OpenPGP digital signature