Réponses:
Le problème est sudo -s
sans aucun argument ouvrira un shell interactif pour root.
Si vous souhaitez simplement exécuter une seule commande à l'aide de sudo -s
, vous pouvez simplement faire:
sudo -s command
Par exemple :
$ sudo -s whoami
root
Ou vous pouvez utiliser ici des chaînes:
$ sudo -s <<<'whoami'
root
Si vous avez plusieurs commandes, vous pouvez utiliser ici doc:
$ sudo -s <<'EOF'
> whoami
> hostname
> EOF
root
something--
Une autre façon serait de passer une ou des commandes bash complètes à sudo
:
#!/bin/bash
sudo bash -c 'command1; command2; command3;'
Cependant, une meilleure façon serait de lancer le script avec à la sudo
place. Ce n'est pas une très bonne idée d'avoir sudo
à l'intérieur du script. Il vaut bien mieux exécuter l'intégralité du script avec les privilèges root ( sudo script.sh
). Si nécessaire, vous pouvez utiliser sudo
pour supprimer des privilèges pour des commandes spécifiques. Par exemple:
#!/usr/bin/env bash
whoami
echo $HOME
sudo -u terdon whoami ## drop privileges for specific command.
L'exécution du script ci-dessus renvoie:
$ sudo ~/scripts/a.sh
root
/root
terdon
Le shell Bourne a un -c
drapeau que vous pouvez utiliser pour passer un script arbitraire au shell, afin que vous puissiez écrire quelque chose comme
sudo sh -c 'something'
Ceci n'est cependant utile que pour les commandes les plus simples, car il est très lourd de citer correctement le script et l'inconvénient est encore plus élevé si vous envoyez la commande à un serveur distant via ssh car le script d'argument sera analysé deux fois, une fois sur le côté envoyer le script et une fois sur le côté exécutant le script.
S'il something
s'agit d'un script complexe ou doit être passé sur une ligne ssh , il est courant d'écrire une fonction prepare_something_script
dont le travail consiste à écrire le script «quelque chose» sur stdout . Dans sa forme la plus simple, cette fonction peut utiliser un document ici pour générer sa sortie:
prepare_something_script()
{
cat <<EOF
something
EOF
}
Le script produit par prepare_something_script
peut ensuite être exécuté localement avec les privilèges accordés par sudo comme suit:
prepare_something_script | sudo sh
Dans le scénario où le script doit être exécuté à distance avec les privilèges accordés par sudo, il est habituel de coder le script en base 64 pour éviter de rediriger l'entrée standard de ssh , comme ceci:
something64=$(prepare_something_script | base64)
ssh usesr@remote-host "echo ${something64} | base64 --decode | sudo sh"
Si vous utilisez ce code dans une fonction, n'oubliez pas de marquer la variable something64 comme locale . Certaines implémentations de base64 offrent un -d
indicateur à décoder, qui est moins bien pris en charge que la --decode
variante détaillée . Certaines implémentations nécessitent d'ajouter un -w 0
à la commande de codage pour éviter les sauts de ligne parasites.
sudo -s
au cas où l'root
utilisateur aurait eu l'idée (plutôt mauvaise) de changer de shell. Ce devrait vraiment êtresudo sh
ce qui indique explicitement quel shell doit être utilisé.