bug-bash
[Top][All Lists]
Advanced

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

Re: currently doable? Indirect notation used w/a hash


From: Pierre Gaston
Subject: Re: currently doable? Indirect notation used w/a hash
Date: Fri, 14 Jun 2013 14:30:19 +0300

On Fri, Jun 14, 2013 at 2:25 PM, Dan Douglas <ormaaj@gmail.com> wrote:
> On Friday, June 14, 2013 06:02:15 AM Dan Douglas wrote:
>> On Monday, June 10, 2013 09:39:56 AM Greg Wooledge wrote:
>> > > On 10 Jun 2013 14:15, "Chris F.A. Johnson" <chris@cfajohnson.com> wrote:
>> > > >    It is not the least bit difficult with eval:
>> > > >
>> > > > eval "array=( \"\${$1[@]}\" )"
>> >
>> > On Mon, Jun 10, 2013 at 09:17:23PM +0800, Chris Down wrote:
>> > > Enjoy your arbitrary command execution.
>> >
>> > To be fair, Chris Johnson was probably assuming a programming environment
>> > where the function is only callable from within the same script, and
>> > thus has only trustworthy arguments provided by the caller.  Sometimes,
>> > this is the case.  Sometimes, it isn't.
>> >
>> > In a more general sense, using eval SAFELY requires undergoing several
>> > tedious steps.
>>
>> You're aware of this. For the record, there should never be a situation where
>> a variable name isn't guaranteed. All builtins that accept variable names,
>> arithmetic variable dereferences, and indirect variable expansions are
>> exploitable, not just eval. It never makes sense to have the name of some
>> internal label not controlled entirely internally.
>>
>> If it's a library function used by some other script, then responsibility for
>> making that guarantee is inherited by the library consumer. There's no
>> difference.
>>
>> To validate a "parameter name" fully requires a full shell parser, because 
>> the
>> subscript of an indexed array is effectively a part of its name as far as 
>> Bash
>> is concerned.
>>
>
> Also forgot to mention (though it should be obvious).
>
>  $ ~/doc/programs/bash43 -c 'function f { typeset -n x=$1; : "$x"; }; a=(yo 
> jo); f "a[\$(echo yes this even applies to namerefs>&2)0]"'
> yes this even applies to namerefs
>
> In a nutshell bash namerefs don't actually enable any new functionality. It's
> just a convenient syntax, makes dealing with keys indirectly easier, and
> improves portability in some limited cases.
>
> --
> Dan Douglas
>
Maybe nameref also allows to avoid name clashes (which I believe is
not that easy to workaround now)?



reply via email to

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