Comment forcer explicitement et en toute sécurité l'utilisation d'une commande intégrée dans bash

Il y a une question similaire qui traite du scénario de «wrapping», où vous souhaitez remplacer par exemple cdune commande qui appelle la fonction intégrée cd.

Cependant, à la lumière de shellshock et al et sachant que bash importe des fonctions de l'environnement, j'ai fait quelques tests et je ne peux pas trouver un moyen d'appeler le builtin en toute sécurité à cdpartir de mon script.

Considère ceci

cd() { echo "muahaha"; }
export -f cd

Tous les scripts appelés dans cet environnement à l'aide de cdse briser (considérer les effets de quelque chose comme cd dir && rm -rf .).

Il existe des commandes pour vérifier le type d'une commande (appelée commodément type) et des commandes pour exécuter la version intégrée plutôt qu'une fonction ( builtinet command). Mais, voilà, ceux-ci peuvent également être remplacés à l'aide de fonctions

builtin() { "$@"; }
command() { "$@"; }
type() { echo "$1 is a shell builtin"; }

Donnera ce qui suit:

$ type cd
cd is a shell builtin
$ cd x
muahaha
$ builtin cd x
muahaha
$ command cd x
muahaha

Existe-t-il un moyen de forcer en toute sécurité bash à utiliser la commande intégrée, ou au moins détecter qu'une commande n'est pas une commande intégrée, sans effacer tout l'environnement?

Je me rends compte que si quelqu'un contrôle votre environnement, vous êtes probablement foutu de toute façon, mais au moins pour les alias, vous avez la possibilité de ne pas appeler l'alias en insérant un \avant.

Olivier D est presque correct, mais vous devez vous mettre POSIXLY_CORRECT=1avant de courir unset. POSIX a une notion de Special Built-ins , et bash la prend en charge . unsetest un tel intégré. Rechercher SPECIAL_BUILTINdans builtins/*.cla source de bash pour une liste, il comprend set, unset, export, evalet source.

$ unset() { echo muahaha-unset; }
$ unset unset
muahaha-unset
$ POSIXLY_CORRECT=1
$ unset unset

Le voleur unseta été retiré de l'environnement, si vous enlevez command, type, builtinalors vous devriez être en mesure de procéder, maisunset POSIXLY_CORRECT si vous comptez sur le comportement non-POSIX ou fonctionnalités avancées de bash.

Cela ne concerne pas les alias, vous devez donc utiliser \unsetpour être sûr que cela fonctionne dans le shell interactif (ou toujours, si le cas expand_aliasesest en vigueur).

Pour les paranoïaques, cela devrait tout arranger, je pense:

POSIXLY_CORRECT=1
\unset -f help read unset
\unset POSIXLY_CORRECT
re='^([a-z:.\[]+):' # =~ is troublesome to escape
while \read cmd; do 
    [[ "$cmd" =~ $re ]] && \unset -f ${BASH_REMATCH[1]}; 
done < <( \help -s "*" )

( while, do, doneEt [[sont des mots réservés et ne précautions ont pas besoin.) Notez que nous utilisons unset -fpour être sûr de fonctions non définies, bien que les variables et les fonctions partagent le même espace , il est possible pour que les deux existent simultanément (grâce à Etan Reisner) auquel cas Unset-ing deux fois ferait aussi l'affaire. Vous pouvez marquer une fonction en lecture seule, bash ne vous empêche pas de désactiver une fonction en lecture seule jusqu'à bash-4.2 inclus, bash-4.3 vous en empêche, mais il honore toujours les commandes spéciales lorsquePOSIXLY_CORRECT est défini.

Une lecture seule POSIXLY_CORRECTn'est pas un vrai problème, ce n'est pas un booléen ou un indicateur sa présence active le mode POSIX, donc s'il existe en lecture seule, vous pouvez compter sur les fonctionnalités POSIX, même si la valeur est vide ou 0. Vous aurez simplement besoin de fonctions problématiques non définies d'une manière différente de celle ci-dessus, peut-être avec un copier-coller:

\help -s "*" | while IFS=": " read cmd junk; do echo \\unset -f $cmd; done

(et ignorez toutes les erreurs) ou engagez-vous dans d'autres scripts .

Autres notes:

• functionest un mot réservé, il peut être aliasé mais pas remplacé par une fonction. (L'aliasing functionest légèrement gênant car il \function n'est pas acceptable comme moyen de le contourner)
• [[, ]]sont des mots réservés, ils peuvent être aliasés (qui seront ignorés) mais pas remplacés par une fonction (bien que les fonctions puissent être ainsi nommées)
• (( n'est pas un nom valide pour une fonction, ni un alias

Je me rends compte que si quelqu'un contrôle votre environnement, vous êtes probablement foutu de toute façon

Oui ça. Si vous exécutez un script dans un environnement inconnu, toutes sortes de choses peuvent mal se passer, en commençant par LD_PRELOADfaire en sorte que le processus shell exécute du code arbitraire avant même de lire votre script. Tenter de se protéger contre un environnement hostile depuis l'intérieur du script est futile.

Sudo a assaini l'environnement en supprimant tout ce qui ressemble à une définition de fonction bash depuis plus d'une décennie. Depuis Shellshock , d'autres environnements qui exécutent des scripts shell dans un environnement non entièrement fiable ont emboîté le pas.

Vous ne pouvez pas exécuter un script en toute sécurité dans un environnement qui a été défini par une entité non approuvée. S'inquiéter des définitions de fonction n'est donc pas productif. Assainissez votre environnement et, ce faisant, les variables que bash interpréterait comme des définitions de fonction.

Vous pouvez utiliser unset -fpour supprimer les fonctions intégrées, la commande et le type.