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 >> >