[Top][All Lists]

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

Re: declare a="$b" if $a previously set as array

From: Linda Walsh
Subject: Re: declare a="$b" if $a previously set as array
Date: Mon, 15 Dec 2014 18:41:56 -0800
User-agent: Thunderbird

Chet Ramey wrote:
On 12/8/14 4:56 AM, Stephane Chazelas wrote:

I'm saying that if a script writer writes:

    declare a="$b"

I don't think it's unreasonable for a script writer to expect that
this does not unset a; it's not documented to do that, and assignment
without the `declare' doesn't unset it.  Assignment without declare
also pays attention to the variable's state: assigning to `a' as if it
were a scalar doesn't magically convert it from an array to a scalar;
it assigns element 0, as you know.
        Similarly, if you use 'set', or 'shopt', they doesn't reset
all the state variables addressable w/those commands.  declare can
be used to toggle those variable attributes w/o destroying the rest.

Though I just ran into a bit of weirdness (in 4.2.45)
(output is commented out and indented):

env -i /bin/bash --norc --noprofile
declare -a ar=(ONE TWO THREE)
declare -p ar
#       declare -a ar='([0]="ONE" [1]="TWO" [2]="THREE")'

#### add 'l', and note output:

declare -al ar=(address@hidden)
declare -p ar
# declare -al ar='([0]="ONE" [1]="TWO" [2]="THREE")' # Note - no conversion

# ok, now set export:
declare -x ar=(address@hidden)
declare -p ar
declare -axl ar='([0]="one" [1]="two" [2]="three")' # now "-l" takes effect

Same thing happened w/integers... delayed conversion.

Weird. prolly fixed. (?)

- it will work in most of the cases (and that's one aspect why
it's dangerous, because it's hard to detect).
- but you've got a code injection vulnerability (in the very
special case where $b starts with "(".
- for no good reason. See ksh for a better syntax that doesn't
have the issue.
It is code injection because the script writer is using unchecked

That's why I thought it might be a "way out" to "evolve" bash to
know what vars come from the user or the environment -- then
shopt -o no_eval_tainted

would throw an error on *any* eval (whether it uses 'eval' or
not).  (obviously not happening overnight, but it would be
more than a simple band-aid correcting this one use case

It's still a script writer's responsibility to check input
before blindly using it: this isn't considered a bug in
the C language -- but it is considered unsafe practice:

     char * buff = getenv("PATH");

Do you really think BASH should be changed because of
bad practice?

reply via email to

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