Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11264

Re: cannot declare local variables if they're readonly

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> (permalink)
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
X-Trace usenet.stanford.edu 1437691937 23272 208.118.235.17 (23 Jul 2015 22:52:17 GMT)
X-Complaints-To action@cs.stanford.edu
Cc Greg Wooledge <wooledg@eeg.ccf.org>, bug-bash <bug-bash@gnu.org>
To chet.ramey@case.edu
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tbju3WL4W8aOYAQo8w3TcI/kz9JB5pAyjxdemvcy+Lc=; b=Hj/mO4eOxvL+w1DPFxVDX/bNP+cHPkIA6p7Ajj/KS/5ZHUZhGYezRLDT9hH/duIAAF HUn6VAmcX3mG/c9qyYZs80CBPje8Wcr2XsFI/5CyyzgekOjbAtMi6BwFxNxGQ/PzobI+ Iv2FkVKTc4ZAu2CjIkffvzlIorRfgeR0w1e/SLts+dltt/Xi9rpakfk2Twas58wSEA2m fEiTIxeOGK640MwSaYlyj7reWBqfUwIunsTGogejEckaKP/k+JsOnulcfurSc/5l8K7X yl6eVGkAPbdGIIk52dsnYZCncDMHgibZhN1OnnkEOBkFd3kTWKAFKPFKo1zvJ3NBB6l7 YRtw==
X-Received by 10.50.40.42 with SMTP id u10mr97437igk.71.1437691932939; Thu, 23 Jul 2015 15:52:12 -0700 (PDT)
In-Reply-To <55B157A1.7020306@case.edu>
X-detected-operating-system by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value).
X-Received-From 2607:f8b0:4001:c03::235
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.14
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <http://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref aioe.org gnu.bash.bug:11264

Show key headers only | View raw


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

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: cannot declare local variables if they're readonly isabella parakiss <izaberina@gmail.com> - 2015-07-24 00:52 +0200

csiph-web