[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preventing Bash Variable Confusion
From: |
Greg Wooledge |
Subject: |
Re: Preventing Bash Variable Confusion |
Date: |
Wed, 29 Jan 2020 13:57:48 -0500 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Thu, Jan 30, 2020 at 01:03:31AM +0700, Robert Elz wrote:
> It actually doesn't, or not generally - it allows the function to avoid
> namespace collisions with random globals (or other locals) that might exist
> up the call stack, but doesn't prevent functions that are called from
> trampling all over this function's local vars.
OK, true. But then the real issue is that you're calling broken functions.
Stop calling broken functions.
Yeah, yeah, I know, trying to get people to STOP WRITING broken functions
is impossible... but still, you shouldn't be running around with the
idea in your head that bash scripts should use LIBRARIES OF FUNCTIONS.
The language is just not robust enough for that to work in real life.
A script is supposed to be a self-contained entity, as much as possible.
It isn't supposed to be part of some web of tangled dependencies.
> It could be fixed by
>
> sigint_handler() {
> command local My_Var=$$
> command trap - INT
> command kill -s INT "${My_Var}"
> }
You mean "builtin" instead of "command" in every one of those cases,
right? Well, if you're using maliciously broken "library functions"
in a bash script, the problem is, the malicious library can also
override the "command" command and the "builtin" command.
And yes, it can also override the "/bin/kill" command and so on.
Untrusted libraries are HIDEOUSLY EVIL in bash. There is no workaround,
other than those I've already stated.
Re: Preventing Bash Variable Confusion, konsolebox, 2020/01/29