Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11255
| From | Stephane Chazelas <stephane.chazelas@gmail.com> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: cannot declare local variables if they're readonly |
| Date | 2015-07-23 11:29 +0100 |
| Message-ID | <mailman.7297.1437656727.904.bug-bash@gnu.org> (permalink) |
| References | <CAAZkfo+DWFdcabbcfq69EC-s3RvrxGRRfccLng_1sOjQQ9W1=Q@mail.gmail.com> |
2015-07-23 01:12:01 +0200, isabella parakiss:
> From variables.c
>
> The test against old_var's context
> level is to disallow local copies of readonly global variables (since I
> believe that this could be a security hole).
>
> Can you please explain how that can be a security hole?
>
>
> $ readonly wtf; fn () { local wtf; }; fn
> bash: local: wtf: readonly variable
>
> You can't even be sure that you can set *local* variables in a function.
> This is a problem.
>
> Most of the shells that support local variables (ksh93, mksh, zsh, dash...)
> allow this. The only one I could find that doesn't is busybox.
[...]
I agree with you. That was discussed on another list a few
months ago. Unfortunately Chet seems to be of a different
opinion:
http://www.zsh.org/mla/workers/2015/msg00924.html
To be fair, you also need to consider cases like:
readonly c=299792458
light_year() {
REPLY=$((c * 86400 * 365))
}
my_func() {
local a=1 b=2 c=3
light_year "$((a + b + c))"
}
What that means is that with this kind of dynamic scoping,
"readonly" is not very helpful. I don't remember ever using it.
--
Stephane
Back to gnu.bash.bug | Previous | Next | Find similar
Re: cannot declare local variables if they're readonly Stephane Chazelas <stephane.chazelas@gmail.com> - 2015-07-23 11:29 +0100
csiph-web