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. David Korn is insistent that if POSIX standardizes typeset that only static scoping be standardized, whereas bash currently only implements dynamic scoping (but static scoping could be added on top of that, via appropriate options to typeset). Overriding statically scoped variables is not a security risk, but overriding dynamically scoped variables is asking for problems. I agree with bash's current implementation restrictions, given its current scoping rules. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
