Salut

J'écris un script qui aurait besoin d'exécuter certains commandes en root, tandis que d'autres devraient l'être en tant qu'utilisateur.

On est d'accord que l'utilisateur exécutant le script doit avoir les droits root pour l'exécuter, aucun problème.

Mais comment, à l'intérieur du script, pourrais-je passer de l'utilisateur à root, et de root à l'utilisateur ?

L'utilisateur lancerait probablement sudo script.sh

il y a plusieurs facon de faire ca. Probablement la plus standard est de ne mettre sudo que devant les commandes qui ont vraiment besoin d'etre executer en root.

Le 28 juillet 2021 à 16:04:01 :
il y a plusieurs facon de faire ca. Probablement la plus standard est de ne mettre sudo que devant les commandes qui ont vraiment besoin d'etre executer en root.

Oui mais le script ne doit pas être interactif, donc ne pas demander le mot de passe pendant son exécution

J'aurais dû le préciser avant

bah quand tu veux aller en root, tu fais la commande su et tu entres ton mot de passe. Puis pour repasser à l'utilisateur user, tu fais exit, on est d'accord ?
Voilà, je pense que tu as ta solution 🤷‍♂️

Le 28 juillet 2021 à 17:03:14 :

Le 28 juillet 2021 à 16:24:35 [Soft]Ware a écrit :

Le 28 juillet 2021 à 16:04:01 :
il y a plusieurs facon de faire ca. Probablement la plus standard est de ne mettre sudo que devant les commandes qui ont vraiment besoin d'etre executer en root.

Oui mais le script ne doit pas être interactif, donc ne pas demander le mot de passe pendant son exécution

J'aurais dû le préciser avant

Lance le en root et sudo en utilisateur normal les commandes qui doivent être exécutées en utilisateur normal

ah oui mais il veut pas que le mot de passe soit entré. Dans tous les cas il devra être entré, sauf si tu boot sur l'utilisateur root (comme sur FreeBSD au login par exemple)

Le 28 juillet 2021 à 17:13:58 :

Le 28 juillet 2021 à 17:05:36 pepitomlg a écrit :

Le 28 juillet 2021 à 17:03:14 :

Le 28 juillet 2021 à 16:24:35 [Soft]Ware a écrit :

Le 28 juillet 2021 à 16:04:01 :
il y a plusieurs facon de faire ca. Probablement la plus standard est de ne mettre sudo que devant les commandes qui ont vraiment besoin d'etre executer en root.

Oui mais le script ne doit pas être interactif, donc ne pas demander le mot de passe pendant son exécution

J'aurais dû le préciser avant

Lance le en root et sudo en utilisateur normal les commandes qui doivent être exécutées en utilisateur normal

ah oui mais il veut pas que le mot de passe soit entré. Dans tous les cas il devra être entré, sauf si tu boot sur l'utilisateur root (comme sur FreeBSD au login par exemple)

???

laisse tomber, dans tous les cas le mot de passe doit être entré s'il veut faire un script contenant une commande sudo dedans, c'est tout ce qu'il faut savoir x)
du coup bah il pourra pas réellement faire son script free-interactive, il sera obligé de saisir le mot de passe lors de son exécution

beh pourquoi ?

Le 28 juillet 2021 à 17:17:07 :

Le 28 juillet 2021 à 17:13:58 :

Le 28 juillet 2021 à 17:05:36 pepitomlg a écrit :

Le 28 juillet 2021 à 17:03:14 :

Le 28 juillet 2021 à 16:24:35 [Soft]Ware a écrit :

> Le 28 juillet 2021 à 16:04:01 :

>il y a plusieurs facon de faire ca. Probablement la plus standard est de ne mettre sudo que devant les commandes qui ont vraiment besoin d'etre executer en root.

Oui mais le script ne doit pas être interactif, donc ne pas demander le mot de passe pendant son exécution

J'aurais dû le préciser avant

Lance le en root et sudo en utilisateur normal les commandes qui doivent être exécutées en utilisateur normal

ah oui mais il veut pas que le mot de passe soit entré. Dans tous les cas il devra être entré, sauf si tu boot sur l'utilisateur root (comme sur FreeBSD au login par exemple)

???

laisse tomber, dans tous les cas le mot de passe doit être entré s'il veut faire un script contenant une commande sudo dedans, c'est tout ce qu'il faut savoir x)
du coup bah il pourra pas réellement faire son script free-interactive, il sera obligé de saisir le mot de passe lors de son exécution

T'es con ?

Y a énormément de cas où sudo ne demandera pas le mot de passe hein, encore faut-il comprendre comment sudo marche

le gars veut faire un script qu'il lancera où il veut passer de l'utilisateur user à root. Essaie de faire ça et dis moi s'il ne faut pas le mot de passe lors de l'exécution du script...

Bref l'auteur, y a plusieurs solutions selon ce que tu veux faire précisément, je donne quelques idées en vrac

1) Tu run le script en root d'une façon ou d'une autre

Dans le script t'utilises sudo -u user pour exécuter en tant que l'utilisateur que tu veux

Le mot de passe sera pas demandé normalement, s'il l'est tu peux configurer ton /etc/sudoers pour que root n'ait pas besoin de rentrer son password pour utiliser sudo (keyword: NOPASSWD)

2) Tu run le script en tant que l'utilisateur normal

Dans le script t'utilises sudo pour lancer en tant que root

Tu rajoutes des règles dans ton /etc/sudoers pour autoriser l'utilisateur à run les commandes (que tu peux whitelister) sans entrer son mot de passe

3) Tu run le script en tant que l'utilisateur normal

Dans le script tu utilises sudo pour lancer en tant que root

Et tu te débrouilles pour que le script ait une session sudo valide le temps de l'exécution de sorte que sudo ne redemande pas le mot de passe (keyword: sudo session)

Le 28 juillet 2021 à 18:28:35 :
le gars veut faire un script qu'il lancera où il veut passer de l'utilisateur user à root. Essaie de faire ça et dis moi s'il ne faut pas le mot de passe lors de l'exécution du script...

Gros tu connais absolument rien au fonctionnement de sudo, ferme la

La solution la plus simple : tu modifies /etc/sudoers et tu rajoutes NOPASSWD dans la ligne qui contient la règle concernant ton utilisateur

T'es typiquement l'ubuntu user de base qui utilise des outils qu'il comprend pas en te contenant de copier coller des commandes

dans tous les cas le mot de passe doit être entré s'il veut faire un script contenant une commande sudo dedans

tu dois entrer le mot de passe pour modifier le fichier /etc/sudoers

ps : c'est en faisant des erreurs qu'on apprend. je fais des erreurs, certes, mais au moins c'est bon j'ai compris et je le reconnais ;) pas besoin d'être hostile. c'est typique de la communauté linux ça...

Une 4e solution

Tu actives le suid bit du script, tu changes l'owner du script par root de sorte que quand tu le run avec n'importe quel utilisateur il s'exécutera avec les permissions root et ensuite t'utilises sudo comme dans 1)

(Attention à pas faire n'importe quoi dans le script si tu choisis cette solution et surtout laisse pas l'accès en écriture au fichier)

Le 28 juillet 2021 à 18:39:06 :

dans tous les cas le mot de passe doit être entré s'il veut faire un script contenant une commande sudo dedans

tu dois entrer le mot de passe pour modifier le fichier /etc/sudoers

ps : c'est en faisant des erreurs qu'on apprend. je fais des erreurs, certes, mais au moins c'est bon j'ai compris et je le reconnais ;) pas besoin d'être hostile. c'est typique de la communauté linux ça...

Ok je feed pas plus longtemps ce troll de piètre qualité

Le 28 juillet 2021 à 18:40:44 :

Le 28 juillet 2021 à 18:39:06 :

dans tous les cas le mot de passe doit être entré s'il veut faire un script contenant une commande sudo dedans

tu dois entrer le mot de passe pour modifier le fichier /etc/sudoers

ps : c'est en faisant des erreurs qu'on apprend. je fais des erreurs, certes, mais au moins c'est bon j'ai compris et je le reconnais ;) pas besoin d'être hostile. c'est typique de la communauté linux ça...

Ok je feed pas plus longtemps ce troll de piètre qualité

tu viens de le faire pourtant mdrrr
t'aurais très bien pu choisir de m'ignorer, mais non. monsieur a continué de feed mon "troll" (d'ailleurs je vois pas en quoi c'est du troll... j'essaie d'apprendre, c'est tout ) tout en profitant d'insulter un débutant, se croyant supérieur à tous car il a la réponse à donner à l'OP

Le 28 juillet 2021 à 18:40:22 :
Une 4e solution

Tu actives le suid bit du script, tu changes l'owner du script par root de sorte que quand tu le run avec n'importe quel utilisateur il s'exécutera avec les permissions root et ensuite t'utilises sudo comme dans 1)

(Attention à pas faire n'importe quoi dans le script si tu choisis cette solution et surtout laisse pas l'accès en écriture au fichier)

suid un script est toujours une mauvaise idee. Il y a trop de facon de changer le comportement d'un script de facon externe. Et il y a des OS qui ne te laisse pas faire ca de toute facon. (Un script lit plein de variable d'environment et peut avoir un comportement qui depends du terminal.) C'est une tres vielle recommendation unix. Plus recement, ca en parle ici: https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts

De ce que OP en dit, ce que tu veux est lancer le script avec sudo pour faire la gestion des permissions a ce moment la, et que le script su vers un utilisateur particulier quand il a beson d'avoir une autre identite.

Le 28 juillet 2021 à 19:33:38 :

Le 28 juillet 2021 à 18:40:22 :
Une 4e solution

Tu actives le suid bit du script, tu changes l'owner du script par root de sorte que quand tu le run avec n'importe quel utilisateur il s'exécutera avec les permissions root et ensuite t'utilises sudo comme dans 1)

(Attention à pas faire n'importe quoi dans le script si tu choisis cette solution et surtout laisse pas l'accès en écriture au fichier)

suid un script est toujours une mauvaise idee. Il y a trop de facon de changer le comportement d'un script de facon externe. Et il y a des OS qui ne te laisse pas faire ca de toute facon. (Un script lit plein de variable d'environment et peut avoir un comportement qui depends du terminal.) C'est une tres vielle recommendation unix. Plus recement, ca en parle ici: https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts

De ce que OP en dit, ce que tu veux est lancer le script avec sudo pour faire la gestion des permissions a ce moment la, et que le script su vers un utilisateur particulier quand il a beson d'avoir une autre identite.

Exact, mais encore une fois on connait pas l'use case de l'auteur. Selon son use case utiliser le suid bit peut être la meilleure solution.

C'est typiquement pas impossible qu'il soit dans un contexte où la sécurité n'est pas importante, par exemple s'il bidouille un système isolé qui ne contient rien de sensible.

Petite contribution :

J'avais conçu un p'tit script pour installer Arch en auto (et m'éviter de taper des lignes que je connaissais par cœur)

Durant l'étape de création d'utilisateur j'assignais un mot de passe à celui-ci avec :

echo -e "pass\npass"  | passwd user

C'est un exemple qui s'applique dans le cas du mot de passe, le morceau qui t'intéresse doit ressembler plutôt à ça :

echo -e "pass\npass"  | sudo la_commande_nécessitant_ton_mdp

à noter que le "\n" permet de le retour à la ligne et n'est pas compris dans le mot de passe (si jamais il y a un doute ^^)

C'est... comme certains te l'ont mentionner pas vraiment une option à envisager pour tout un tas de raisons que je ne vais pas bêtement répéter mais t'est prévenu et responsable de tes propres actions donc.

Ah ouais vous êtes partis en guerre

Rentrer le mot de passe évidemment c'est pas un problème.
Mais la durée d'exécution du script est longue (plusieurs heures, dépendant du CPU).

Donc demander le mot de passe au tout début, OK, mais le demander en plein milieu, non.

Le lancer :

sudo script.sh

Là le mot de passe sera demandé, donc OK aucun problème.

En gros le script est de la forme :

# commande lancée en user
cmd-user1

# 1 heure est passée

# commande lancée en root
cmd-root2

# 1 heure est passée

# commande lancée en user
cmd-user3

# 1 heure est passée

# commande lancée en root
cmd-root4

Si je met simplement un sudo devant les cmd-root, le mot de passe aura expiré.
Le script étant lancé en tant que root, je pense qu'il faudrait simplement pouvoir lancer des commandes en tant qu'utilisateur.
Mais du coup, comment je sais de quel utilisateur il s'agit dans le script, puisque je l'ai lancé en tant que root ?

Tu ne veux pas que le script contiennent les commandes qui s'execute en root et les commandes qui s'executent en non root dans le meme script.
Poyur changer d'utilisateur il va falloir changer de process. Et probablement tu ne veux pas que les commande qui tournent sur un utilisateur non privilegier puisse contaminer ton environement en root. Donc tu as en gros deux choix:

1/ tu fais tourner en utilisateur non privilegie que les quelques commandes qui ont besoin de l'etre
2/ tu separe ton script en deux script different et tu lance le script utilisateur avec les permissions qui vont bien.

(je compose un exemple simple)