On 2021/06/29 15:49, Greg Wooledge wrote:
On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
Using that with your input:
njobs 'x[0$(date >&2)]'
bash: printf: `x[0$(date': not a valid identifier
This is because you didn't quote "$1".
----
$1 should never be quoted -- it is an identifier, and as such
cannot contain a space. By quoting it, you are allowing inputs that
would otherwise be filtered out because they are not valid variable
names.
Since you only ever tested
the cases where $1 was a valid variable name
----
It is only designed to work with $1 being an optional, valid
variable name.
Anything else should fail. There are times when putting quotes around a
var will enable problems.
, you never ran into that particular result... until now.
----
I never ran into "invalid input" because I didn't program it to
accept anything other than a variable name there.
As you can see, the unquoted $1 underwent word splitting, so you're
effectively running printf -v 'x[0$(date' '>&2)]' '%s\n' "...".
----
Which is detected as "illegal input" and disallowed. If you don't
enable
some security errors, they can't be as easily introduced. I assert that you
should never put quotes around something that is supposed to be a
variable name
since valid variable names can not be word-split. Many of the items on your
website about bash cautions, are because bash disallows some sketchy
constructs.
That's not a bash-caveat, but a bash feature!
This won't protect against all code injections, of course; only the
ones that contain a whitespace character.
----
Nothing protect against "all" 'X' or "everything", especially when
talking
about security. Security is best handled as a layered approach with
different
layers protecting against different things. There's no such thing as a
'Security Magic Bullet'. Just because NOTHING protects against "ALL"
[anything] is
not a reason to take extreme action. In fact realization that NOTHING is
perfect
is one of the better defenses against over-reacting in response to
supposed security
flaws.
