Pour une raison quelconque, j'ai besoin, en tant qu'utilisateur, d'exécuter sans Sudo un script script.sh qui nécessite des privilèges root pour fonctionner.
Je considérais que la seule solution pour mettre Sudo INSIDE script.sh. Prenons un exemple:
script.sh :
#!/bin/sh
Sudo apt-get update
Bien sûr, si j'exécute ce script, je reçois une invite me demandant un mot de passe. Puis j'ai ajouté à mon fichier sudoers (à la fin pour tout remplacer):
user ALL=(ALL:ALL) NOPASSWD:/path/to/script.sh
Au fait, j'ai aussi essayé la ligne:
user ALL=(ALL) NOPASSWD:/path/to/script.sh
(Je pense que je n'ai pas bien compris la différence)
Mais cela ne résout pas mon problème si je n'utilise pas Sudo pour exécuter ce script:
# ./script.sh
[Sudo] password for user:
# Sudo ./script.sh
Starts updating...
Bien, alors je me dis "Ok, ça veut dire que si j'ai un fichier référencé dans sudoers comme je le faisais, ça fonctionnera sans invite seulement si je l'appelle avec Sudo, ce qui n'est pas ce que je veux".
Alors, d'accord, je crée un autre script, script2.sh, comme suit:
script2.sh
#!/bin/sh
Sudo /path/to/script.sh
En fait ça marche. Mais je ne suis pas vraiment satisfait de cette solution, notamment par le fait que je dois utiliser 2 scripts pour chaque commande.
Cet article est ensuite destiné à aider les personnes confrontées à ce problème et à rechercher la même solution (je n’ai pas trouvé un bon article à ce sujet), et peut-être que de meilleures solutions viennent de vous.
N'hésitez pas à partager vos idées!
EDIT 1:
Je tiens à insister sur le fait que cette "apt-get update" n'était qu'un exemple FAR de ce que mon script est en réalité. Mon script a beaucoup de commandes (avec quelques cd pour les fichiers de configuration root-access-only), et la solution ne peut pas être "Eh bien, faites-le directement avec apt-get".
Le principe d'un exemple est d'aider à la compréhension, pas d'être une excuse pour simplifier la réponse au problème général.
Si vous voulez exécuter Sudo /usr/bin/apt-get update
sans mot de passe, vous devez avoir l'entrée sudoers:
user ALL=(ALL:ALL) NOPASSWD:/usr/bin/apt-get update
Pour l’ensemble du problème du script dans son ensemble, deux approches sont possibles:
Pour chaque commande du script nécessitant Sudo
, créez une ligne dans sudoers
spécifiquement pour cette commande. Dans ce cas, le script peut être appelé normalement:
./script1.sh
Placez une ligne dans sudoers
pour le script dans son ensemble. Lorsque cela est fait, les commandes individuelles n'ont pas besoin de Sudo
. Cependant, Sudo
doit être utilisé pour démarrer le script comme suit:
Sudo ./script.sh
De mon blog: IDMRockstar.com :
Le kicker est que parfois, j'ai besoin d'exécuter des commandes en tant que root. Voici le moyen rapide et sale que j'accomplis sans divulguer les mots de passe:
#! /bin/bash
read -s -p "Enter Password for Sudo: " sudoPW
echo $sudoPW | Sudo -S yum update
De cette façon, l'utilisateur est invité à entrer le mot de passe (et est caché du terminal), puis transmis aux commandes selon les besoins, je n'exécute donc pas l'intégralité du script en tant que root =)
Si vous avez un meilleur moyen, j'aimerais l'entendre! Je ne suis en aucun cas un expert en scripts de Shell.
À votre santé!
.: Adam
Si votre mot de passe ne vous intéresse pas (par exemple, certains serveurs de test de la société, etc.), vous pouvez élever Sudo dans le script via echo, par exemple:
echo YourPasswordHere | Sudo -S Command
L'invite continue d'imprimer le texte "entrer le mot de passe" à afficher. Alors ne vous attendez pas à ce que ce soit soigné.
Voir ceci Post Askubuntu
Comme vous l'avez noté, le fichier qui doit apparaître dans la configuration sudoers est celui qui est lancé par Sudo
et non celui qui exécute Sudo
.
Cela étant dit, ce que nous faisons souvent, c'est d'avoir quelque chose comme
user ALL=(ALL:ALL) NOPASSWD:/path/to/script.sh
dans la configuration Sudo
, où script.sh
contient toutes les commandes que le script doit exécuter.
Ensuite, nous définissons une fonction Bash ou un alias pour que script.sh
soit réellement
Sudo /path/to/script.sh
Le seul problème est que si certaines commandes ne doivent pas être exécutées en tant que root, vous devez insérer des commandes su - user -c "command"
dans le script.
Je vous suggère d’examiner les variables d’environnement Sudo - vous pouvez notamment utiliser (et vérifier) $ Sudo_USER. Appelez votre script avec Sudo (1 entrée dans sudoers), puis créez des éléments utilisateur en tant que Sudo_USER et des éléments racine en tant que root.
Simplement, pour exécuter des commandes en tant que root, vous devez utiliser su (même Sudo utilise su) Tant que vous exécutez Sudo ./script2.sh avec succès à la place: Sudo su "#" // commande en tant que root ici "#" exit//commands as use herevous pouvez en faire une fonction Shell avec le nom Sudo, mais pas d'autre moyen, mais c'est le cas des scripts inti, rc Android ..etc doit être rangé;)
cependant, cela nécessite que vous mettiez NOPASSWD: su qui est totalement sécurisé.
toute méthode ici manque simplement du principe de permission de POISX qui filtre, il ne faut donc pas permettre quelque chose à tous les utilisateurs ou vice-versa Simplement, appelez Sudo autant que vous le souhaitez, sans rien ajouter:
chown root script.sh
chmod 0755 script.sh
chgrp Sudo script.sh
"rendre le propriétaire racine de .sh" "le rendre en lecture seule et exécuter pour les autres" "et le mettre dans le groupe Sudo" bien sûr sous Sudo c'est tout
Dans le nouveau fichier /etc/sudoers.d/apt-get, mettez une seule ligne:
user ALL=(ALL:ALL) NOPASSWD:/usr/bin/apt-get update
Un chemin complet vers l'exécutable est requis ici.
Ensuite, utilisez ce qui suit dans votre script:
Sudo apt-get update
Ici, le nom complet n'est pas requis. Sudo utilise la variable d’environnement PATH pour la résolution des exécutables.
Lors de la modification et de la vérification de la configuration de sudoers, veillez à laisser une autre session racine ouverte pour permettre la récupération des erreurs.