[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: typeset -r prevents local variable of same name.

From: Eric Blake
Subject: Re: typeset -r prevents local variable of same name.
Date: Thu, 17 Feb 2011 20:12:11 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]