Re: [Help-bash] avoiding shell variable expansion

[Eli Schwartz]

On 10/3/19 3:47 PM, Greg Silverman wrote:
> In Python one  can spawn a child process and avoid bash expanding command 
> line arguments, e.g.
> 
> //file: ls.py
> import subprocess
> proc = subprocess.Popen(['/bin/ls','*'],shell=False)
> 
> then
> ./ls.py
> /bin/ls: cannot access '*': No such file or directory
> 
> As the shell argument is set to False, the ls command is not passed to bash 
> before being executed and the star is not expanded to ${PWD}.
> 
> Is there a way to launch a command from a bash script which, also, avoids 
> shell expansion?

You may disable shell expansion of globs or of word splitting
(whitespace) by single quoting or double quoting your glob, as such:

ls '*'

ls "*"

ls 'my important directory/'

ls "my important directory/"

Single or double quotes also prevents the use of things like:

$ ls '&&' true
ls: cannot access '&&': No such file or directory
ls: cannot access 'true': No such file or directory

because && is no longer shell syntax when quoted -- it is simply one of
the filenames passed to the "ls" program.

Or:

$ 'if' ls; 'then' true; 'fi'
bash: if: command not found
bash: then: command not found
bash: fi: command not found

It also suppresses aliases.

$ alias echo='echo prefix'
$ echo foo
prefix foo
$ 'echo' foo
foo


You may disable variable expansion by single quoting:

$ ls '$PWD'
ls: cannot access '$PWD': No such file or directory

But NOT with double quotes.

In general, if you have "exact data, don't do any interpretation", you
should use single quotes.


Note: python subprocess with shell=False has some interesting effects
beyond mere expansion of data. Without a shell, you cannot use shell
builtins like if or read, you obviously cannot use &&, and you also
cannot use shell aliases *or functions* (although shell aliases and
functions are unlikely to exist in a shell=True context either, because
it won't read your .bashrc, so this may be a moot point).

> This question is for security, to avoid code injection.

Code injection is a complex topic. You can avoid some classes of it by
quoting all user-provided input, but some other problems can include:

- generally you want to expand variables

- No bash protections exist for allowing users to inject code as an
  argument to some bash script, which is then faithfully passed to some
  additional binary, and that additional binary contains a code
  injection flaw.

- Some features of bash, like array subscripts
  (x='foo=3' "${array[$x]}") can do code execution, basically anywhere
  that arithmetic evaluation can be done.

In order to ascertain exactly whether there is an issue of code
injection, it would probably be best to see exact bash scripts for analysis.

Understanding how the bash programming language works is important to
effective use of bash, just like understanding how the python
programming language works is important to effective use of python. A
thorough reading of the bash documentation could prove beneficial.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

signature.asc
Description: OpenPGP digital signature