bug-bash
[Top][All Lists]
Advanced

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

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


From: Piotr Grzybowski
Subject: Re: param expansion with single-character special vars in the environment
Date: Thu, 28 Apr 2016 00:47:56 +0200

 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
> 




reply via email to

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