On 2020-10-20 at 09:00, Greg Wooledge wrote:
> On Tue, Oct 20, 2020 at 08:32:12AM -0400, The Wanderer wrote:
>> $ cat /tmp/test-function-script.sh
>> #/bin/bash
>>
>> /home/wanderer/bin/abecedarian.sh
>
> Incorrect shebang (missing the bang half). Therefore, the shell that
> actually gets used is unpredictable. It depends on the caller.
Yeah - pure typo, sorry, I was dashing the script off quickly for the
test. (IIRC I actually had it initially as "#~/bin/bash', and mistakenly
deleted the ~ without adding the !.) I've re-tested with that changed,
and as expected (given that I was running it from bash to begin with) it
behaved identically.
>> $ function /home/wanderer/bin/abecedarian.sh { echo "nope"; }
>> $ abecedarian.sh
>> Usage: /home/wanderer/bin/abecedarian.sh /path/to/wordlist
>> $ /home/wanderer/bin/abecedarian.sh
>> nope
>> $ /tmp/test-function-script.sh
>> Usage: /home/wanderer/bin/abecedarian.sh /path/to/wordlist
>>
>> If I'm parsing that correctly, the full-path invocation from within the
>> script doesn't seem to pick up the function definition from the outside
>> session.
>
> You also forgot to export the function.
I was following the example from the two-liner in your previous post.
The notion that exporting would be needed for the effect to occur had
not occurred to me.
If I just prepend 'export ' to that function-definition line, I get a
syntax error "near unexpected token '}'". If I run a separate 'export
/home/wanderer/bin/abecedarian.sh' after defining the function, I get
"not a valid identifier". If I make that latter 'export -f [etc.]', I
get "cannot export". (By contrast, if I define a function which is not
syntactically an absolute path, 'export [function-name]' and 'export -f
[function-name]' report no errors.)
Maybe I'm still missing something, but so far I'm not seeing a way to
export this, so I still don't see a way it could get exposed inside the
script.
Looking at that, I wouldn't be surprised if it were to turn out that
bash prohibits function-name identifiers which have the form of an
absolute path (or maybe even a relative one containing a directory
reference) from being exported - possibly specifically to avoid this
type of attack.
The man page does say
>>> export returns an exit status of 0 unless an invalid option is
>>> encountered, one of the names is not a valid shell variable name, or -f
>>> is supplied with a name that is not a function.
so the possibility that '/path/to/location' is not a valid shell
variable name seems plausible. It's hard to search the man page for
those terms, because of all the unrelated hits that crop up (especially
with 'name'!), but I've given it a run-through and haven't found
anything that looks like a definition of what is and is not allowed in a
valid shell variable name.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature