web-dev-qa-db-fra.com

Pourquoi devrait-on éviter eval dans Bash et que devrais-je utiliser à la place?

Maintes et maintes fois, je vois les réponses de Bash sur Stack Overflow en utilisant eval et les réponses sont critiquées, pour le jeu de mots, pour l'utilisation d'une telle construction "diabolique". Pourquoi eval est-il si méchant?

Si eval ne peut pas être utilisé en toute sécurité, que dois-je utiliser à la place?

linuxbashunixeval
85
Zenexer

Ce problème ne se limite pas à l’œil. Nous allons commencer par l'évidence: eval a le potentiel d'exécuter des données "sales". Les données sales sont toutes les données qui n'ont pas été réécrites comme sécurisées pour une utilisation dans la situation-XYZ; dans notre cas, c'est une chaîne qui n'a pas été formatée de manière à pouvoir être évaluée en toute sécurité.

La désinfection des données semble facile à première vue. En supposant que nous examinions une liste d'options, bash fournit déjà un excellent moyen de nettoyer les éléments individuels et un autre moyen de nettoyer l'ensemble du tableau en une seule chaîne:

function println
{
    # Send each element as a separate argument, starting with the second element.
    # Arguments to printf:
    #   1 -> "$1\n"
    #   2 -> "$2"
    #   3 -> "$3"
    #   4 -> "$4"
    #   etc.

    printf "$1\n" "${@:2}"
}

function error
{
    # Send the first element as one argument, and the rest of the elements as a combined argument.
    # Arguments to println:
    #   1 -> '\e[31mError (%d): %s\e[m'
    #   2 -> "$1"
    #   3 -> "${*:2}"

    println '\e[31mError (%d): %s\e[m' "$1" "${*:2}"
    exit "$1"
}

# This...
error 1234 Something went wrong.
# And this...
error 1234 'Something went wrong.'
# Result in the same output (as long as $IFS has not been modified).

Maintenant, disons que nous voulons ajouter une option pour rediriger la sortie en tant qu'argument pour println. Nous pourrions, bien sûr, simplement rediriger la sortie de println à chaque appel, mais à titre d'exemple, nous n'allons pas le faire. Nous aurons besoin d'utiliser eval, car les variables ne peuvent pas être utilisées pour rediriger la sortie.

function println
{
    eval printf "$2\n" "${@:3}" $1
}

function error
{
    println '>&2' '\e[31mError (%d): %s\e[m' "$1" "${*:2}"
    exit $1
}

error 1234 Something went wrong.

Ça a l'air bien, non? Le problème, eval analyse deux fois la ligne de commande (dans n’importe quel shell). Lors du premier passage de l'analyse, une couche de citation est supprimée. Avec les guillemets supprimés, certains contenus variables sont exécutés.

Nous pouvons résoudre ce problème en laissant l'expansion variable se dérouler dans eval. Tout ce que nous avons à faire est de tout citer de toutes les citations, en laissant les guillemets là où ils se trouvent. Une exception: nous devons développer la redirection avant eval, de sorte que cela doit rester en dehors des guillemets:

function println
{
    eval 'printf "$2\n" "${@:3}"' $1
}

function error
{
    println '&2' '\e[31mError (%d): %s\e[m' "$1" "${*:2}"
    exit $1
}

error 1234 Something went wrong.

Cela devrait marcher. C'est aussi sûr tant que $1 dans println n'est jamais sale.

Maintenant, attendez un instant: j'utilise la même syntaxe non citée que celle que nous utilisions à l'origine avec Sudo tout le temps! Pourquoi ça marche là et pas ici? Pourquoi avons-nous dû tout citer tout? Sudo est un peu plus moderne: il sait mettre entre guillemets chaque argument reçu, bien que ce soit une simplification excessive. eval concatène simplement tout.

Malheureusement, il n'y a pas de remplacement immédiat pour eval qui traite les arguments comme Sudo, car eval est un shell intégré; c'est important, car il prend en compte l'environnement et la portée du code environnant lors de son exécution, plutôt que de créer une nouvelle pile et une nouvelle portée comme le fait une fonction.

eval Alternatives

Les cas d'utilisation spécifiques ont souvent des alternatives viables à eval. Voici une liste pratique. command représente ce que vous enverriez normalement à eval; remplacez ce que vous voulez.

No-op

Un simple deux-points dans un no-op de bash::

Créer un sous-shell

( command )   # Standard notation

Exécuter la sortie d'une commande

Ne comptez jamais sur une commande externe. Vous devriez toujours avoir le contrôle de la valeur de retour. Mettez ceux-ci sur leurs propres lignes:

$(command)   # Preferred
`command`    # Old: should be avoided, and often considered deprecated

# Nesting:
$(command1 "$(command2)")
`command "\`command\`"`  # Careful: \ only escapes $ and \ with old style, and
                         # special case \` results in nesting.

Redirection basée sur variable

En appelant code, carte &3 (ou quelque chose de plus élevé que &2) à votre cible:

exec 3<&0         # Redirect from stdin
exec 3>&1         # Redirect to stdout
exec 3>&2         # Redirect to stderr
exec 3> /dev/null # Don't save output anywhere
exec 3> file.txt  # Redirect to file
exec 3> "$var"    # Redirect to file stored in $var--only works for files!
exec 3<&0 4>&1    # Input and output!

S'il s'agissait d'un appel ponctuel, vous n'auriez pas à rediriger l'intégralité du shell:

func arg1 arg2 3>&2

Dans la fonction appelée, redirigez vers &3:

command <&3       # Redirect stdin
command >&3       # Redirect stdout
command 2>&3      # Redirect stderr
command &>&3      # Redirect stdout and stderr
command 2>&1 >&3  # idem, but for older bash versions
command >&3 2>&1  # Redirect stdout to &3, and stderr to stdout: order matters
command <&3 >&4   # Input and output!

Indirection variable

Scénario:

VAR='1 2 3'
REF=VAR

Mauvais:

eval "echo \"\$$REF\""

Pourquoi? Si REF contient un guillemet double, cela cassera et ouvrira le code à exploiter. Il est possible d'assainir REF, mais c'est une perte de temps lorsque vous avez ceci:

echo "${!REF}"

C'est vrai, bash a une indirection variable intégrée à partir de la version 2. Cela devient un peu plus compliqué que eval si vous voulez faire quelque chose de plus complexe:

# Add to scenario:
VAR_2='4 5 6'

# We could use:
local ref="${REF}_2"
echo "${!ref}"

# Versus the bash < 2 method, which might be simpler to those accustomed to eval:
eval "echo \"\$${REF}_2\""

Quoi qu'il en soit, la nouvelle méthode est plus intuitive, bien que cela puisse sembler différent des programmeurs expérimentés qui sont habitués à eval.

Tableaux associatifs

Les tableaux associatifs sont implémentés de manière intrinsèque dans bash 4. Une mise en garde: ils doivent être créés avec declare.

declare -A VAR   # Local
declare -gA VAR  # Global

# Use spaces between parentheses and contents; I've heard reports of subtle bugs
# on some versions when they are omitted having to do with spaces in keys.
declare -A VAR=( ['']='a' [0]='1' ['duck']='quack' )

VAR+=( ['alpha']='beta' [2]=3 )  # Combine arrays

VAR['cow']='moo'  # Set a single element
unset VAR['cow']  # Unset a single element

unset VAR     # Unset an entire array
unset VAR[@]  # Unset an entire array
unset VAR[*]  # Unset each element with a key corresponding to a file in the
              # current directory; if * doesn't expand, unset the entire array

local KEYS=( "${!VAR[@]}" )  # Get all of the keys in VAR

Dans les anciennes versions de bash, vous pouvez utiliser l'indirection variable:

VAR=( )  # This will store our keys.

# Store a value with a simple key.
# You will need to declare it in a global scope to make it global prior to bash 4.
# In bash 4, use the -g option.
declare "VAR_$key"="$value"
VAR+="$key"
# Or, if your version is lacking +=
VAR=( "$VAR[@]" "$key" )

# Recover a simple value.
local var_key="VAR_$key"       # The name of the variable that holds the value
local var_value="${!var_key}"  # The actual value--requires bash 2
# For < bash 2, eval is required for this method.  Safe as long as $key is not dirty.
local var_value="`eval echo -n \"\$$var_value\""

# If you don't need to enumerate the indices quickly, and you're on bash 2+, this
# can be cut down to one line per operation:
declare "VAR_$key"="$value"                         # Store
echo "`var_key="VAR_$key" echo -n "${!var_key}"`"   # Retrieve

# If you're using more complex values, you'll need to hash your keys:
function mkkey
{
    local key="`mkpasswd -5R0 "$1" 00000000`"
    echo -n "${key##*$}"
}

local var_key="VAR_`mkkey "$key"`"
# ...
135
Zenexer

Comment sécuriser eval

eval peut être utilisé en toute sécurité - mais tous ses arguments doivent être cités en premier. Voici comment:

Cette fonction qui le fera pour vous:

function token_quote {
  local quoted=()
  for token; do
    quoted+=( "$(printf '%q' "$token")" )
  done
  printf '%s\n' "${quoted[*]}"
}

Exemple d'utilisation:

Compte tenu de certaines entrées utilisateur non fiables:

% input="Trying to hack you; date"

Construire une commande pour eval:

% cmd=(echo "User gave:" "$input")

Évaluez-le, avec apparemment en citant correctement:

% eval "$(echo "${cmd[@]}")"
User gave: Trying to hack you
Thu Sep 27 20:41:31 +07 2018

Notez que vous avez été piraté. date a été exécuté plutôt que d'être imprimé littéralement.

Au lieu de cela avec token_quote():

% eval "$(token_quote "${cmd[@]}")"
User gave: Trying to hack you; date
%

eval n'est pas mauvais - c'est simplement mal compris :)

12
Tom Hale