Path: csiph.com!aioe.org!news.glorb.com!usenet.stanford.edu!not-for-mail
From: isabella parakiss <izaberina@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: cannot declare local variables if they're readonly
Date: Fri, 24 Jul 2015 00:52:12 +0200
Lines: 65
Approved: bug-bash@gnu.org
Message-ID: <mailman.7325.1437691937.904.bug-bash@gnu.org>
References: <CAAZkfo+DWFdcabbcfq69EC-s3RvrxGRRfccLng_1sOjQQ9W1=Q@mail.gmail.com> <20150723121321.GE4309@eeg.ccf.org> <CAAZkfoKHqVm-UgM2OOn6SoR0AN4ZBzERGr=SF5rBzGVMMcaEJA@mail.gmail.com> <55B157A1.7020306@case.edu>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Cc: Greg Wooledge <wooledg@eeg.ccf.org>, bug-bash <bug-bash@gnu.org>
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
In-Reply-To: <55B157A1.7020306@case.edu>
Precedence: list
Xref: aioe.org gnu.bash.bug:11264

On 7/23/15, Chet Ramey <chet.ramey@case.edu> wrote:
> This is an excellent time to point out that it's to everyone's advantage
> to be as complete as possible when describing a problem on the list,
> rather than revealing additional details one at a time.
>
> There's no way anyone would have guessed that you were encountering this
> with BASH_REMATCH; the most likely possibility was that you were trying to
> override a variable you had declared readonly.
>
> Yes, BASH_REMATCH is special.  It's not present by default, and it is
> destroyed and reconstituted fresh every time you use the =~ operator to
> [[, since it's only supposed to exist if something matched.  I suppose
> there's no real reason to make it readonly other than that there's no real
> reason to write to it, and =~ is the only thing that can modify it.
> Removing the restriction on local copies of readonly variables wouldn't do
> a thing to change the BASH_REMATCH semantics, though it would allow scripts
> to unset it.  We would need a different discussion about how you'd like
> BASH_REMATCH to work.
>

No.  Don't minimize this, it's not only about BASH_REMATCH.

The fact that a certain special variable is readonly for no real reason
doesn't change this absurd nonsense about any other global variable.


In one thread you linked in your previous answer, you explained that it
could be a security hole if an admin sets a readonly global variable for
some package, then a new function comes in, changes that value, and then
invokes that package with the new environment.

Consider this stupid example:
fib () {
  local first=$1 second=$2 sum
  sum=$(( first + second ))
  if (( first < 123456 )); then
    fib "$second" "$sum"
    echo "$first"
  fi
}

It seems to work just fine:
$ fib 1 1
121393
75025
....

But it suddenly breaks if first is a readonly global variable.
$ readonly first
$ fib 1 1
bash: local: first: readonly variable
bash: local: first: readonly variable
....

What's the solution for this?  Naming conventions such as fib_local_first?
(Of course that example doesn't even need to declare variables and could
just use $1 and $2 but that's not the point, real scripts do need them)


Is this *not* a security hole?


---
xoxo iza