On 02/17/2011 08:18 PM, Chet Ramey wrote: > On 2/17/11 10:12 PM, Eric Blake wrote: >> On 02/17/2011 07:48 PM, Chet Ramey wrote: >>> Consider a quick, contrived example: an administrator writes a shell >>> package (library, set of functions, whatever) that includes, among >>> other things, ways to make sure that some other package is invoked with >>> a particular set of arguments and environment. He does this in part by >>> declaring some variables readonly. Programs invoked by this package >>> change their behavior depending on the value of environment variables, >>> so it's important to the correct operation of this script that the >>> variables don't change. It should be harder to cirvumvent this, possibly >>> creating a security hole, than just declaring a shell function with a >>> local variable that then calls a public function that expects the variable >>> to have some other value. >> >> Ah, so we're back to the debate of static vs. dynamic scoping. > > Not really. The readonly variables could be declared at the global > scope. Overriding a global variable can cause the same problem.
With static scoping the ONLY place that sees the local variable override is the intermediate shell function. If the intermediate function calls a public function, that public function will still see the (readonly) global variable. (Think C or ksh local variables.) It's only when dynamic scoping is in the mix, where the grandchild function sees the local variables of the intermediate function instead of the global variables, where you no longer want to allow overriding readonly variables. (Think lisp or bash local variables.) I fail to see how overriding a global variable with a statically scoped local can cause problems, since that local cannot be viewed outside the function in a language with static scoping. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
