Re: param expansion with single-character special vars in the environment

[Piotr Grzybowski]

 sorry for the spam concerning the patch: it needs merging with what Eduardo 
posted (excluding the `declare -n r; declare -n r;' regression bug), and what 
is in #ifdef 0 in declare.def; I just found out that it is exactly what it 
intends to do.
 I am sure we need to forbid the illegal identifiers during declare -n and in 
later assignments to the nameref variable.

cheers,
pg

On 28 Apr 2016, at 00:47, Piotr Grzybowski wrote:

> 
> a short summary:
> 
> 1. there is a real bug reported here: allowing namref on illegal identifiers, 
> if we assume that the value of the variable that has nameref attribute is the 
> name of the variable it refers to, then we have to require that declare -n 
> a=b anly allows legal identifiers for b:
> 
> diff --git a/builtins/declare.def b/builtins/declare.def
> index a1e9b4e..53b688c 100644
> --- a/builtins/declare.def
> +++ b/builtins/declare.def
> @@ -719,7 +719,7 @@ declare_internal (list, local_var)
>              if (onref)
>                aflags |= ASS_NAMEREF;
>              v = bind_variable_value (var, value, aflags);
> -             if (v == 0 && onref)
> +             if (v == 0 && onref || ( onref && !legal_identifier(value)))
>                {
>                  sh_invalidid (value);
>                  assign_error++;
> 
> 2. the other matter that you, Grisha, reported, and Eduardo commented heavily 
> on, is not a matter of creating a nameref, but a matter of overriding 
> readonly variables identifiers, a matter of discussion if it should be 
> allowed (coproc bugs and getopt discussed lately being other examples). But 
> it is not a bug, the decision was made to allow namerefs, they work as 
> documented, the readonly variables are not touched, they identifiers are used 
> as per definition of nameref. A matter of discussion should be: how to 
> protect some variables, like the ones that were mentioned (PATH, TMOUT, etc). 
> If the readonly means also "do not give and attributes" then declare -n (and 
> others) should be forbidden on readonly variables. On the other hand we can 
> think of declaring variable as: `protected a' which would mean that no 
> modification of attributes is possible, but variable data can be changed, as 
> opposed to `readonly a' which could mean "data of the variable cannot be 
> changed" and finally both as, e.g.: `exclusive a' meaning readonly|protected.
> 
> 3. I have no idea about this global/local thing Grisha reported.
> 
> cheers,
> pg
> 
> 
> 
> On 25 Apr 2016, at 22:57, Grisha Levit wrote:
> 
>> A related issue is with adding the nameref attribute to a readonly variable. 
>> Not sure if that should be allowed, as it can be used to change the meaning 
>> of the variable, even for variables that bash is using internally:
>> 
>> $ TIMEFORMAT='%R'
>> 
>> $ time bash -c 
>> 'readonly TMOUT=5; read'
>> 5.007
>> 
>> $ time bash -c 
>> 'readonly TMOUT=5; ref=$TMOUT; declare -n ref; ref=10; declare -n TMOUT; 
>> read'
>> 10.004
>> The same technique works for circumventing PATH in a restricted shell:
>> 
>> $ PATH='/restricted/bin' $BASH -r -c 'type sed; ref=$PATH; declare -n ref; 
>> ref=/usr/bin; declare -n PATH; type sed'
>> bash
>> bash: line 
>> 0: type
>> : sed: not found
>> sed is /usr/bin/sed
>> 
>