[Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

Tawal · 19-02-2023 11:20:16

Hello,

Tout est dans le titre non ? <== phrase inutile

En fait, j'ai écrit un script bash utile que pour un utilisateur "normal".
Et donc, il ne doit pas être lancé par root.
Malheureusement, il contient une ligne importante pour son déroulement qui nécessite les droits root.

J'ai une solution un peu moyenne qui utilise pkexec sur cette ligne de commande.
Cela fonctionne.
Mais la demande de mot de passe ne se fait que quand le script atteint cette ligne.

J'aimerais avoir cette demande d'authentification au début du script, et n'utiliser ces effets que sur la ligne concernée.
Voyez-vous une solution ?
Ou avez-vous une autre méthode propre et sécure ?

PS:
Je ne peux pas autoriser le programme via /etc/sudoers car ses arguments sont variables.
Ce qui rendrait l'autorisation bien trop large si je ne l'affine pas avec ses arguments.

Dernière modification par Tawal (01-03-2023 15:09:48)

vv222 · 19-02-2023 12:32:12

C’est assez compliqué comme opération, en général je passe par l’approche inverse : le script doit être exécuté en root, mais diminue lui-même ses privilèges pour toutes les opérations qui ne nécessitent pas d’accès root.

Jean-Pierre Pinson · 19-02-2023 13:15:08

Hello, Tawal.
Je t'ai envoyé un message privé

Tawal · 19-02-2023 14:51:34

@Jean Pierre Poinson : Oui, j'ai vu, je suis en lecture. WeeChat sera sûrement mon choix

@vv222 :
Oui, j'y avais pensé aussi.
Mais ma réflexion s'est arrêtée sur de possibles difficultés :
- comment trouver le bon nom (ou uid) de l'utilisateur "normal" ?
- la lisibilité du script va en pâtir, la commande root se trouve dans des imbrications de tests.

La solution pkexec commande_root me va bien et me convient mieux je trouve (malgré le timing de la demande de mot de passe).
Je n'aime pas trop utiliser root pour "jouer" dans un espace utilisateur ...

vv222 · 19-02-2023 16:48:07

Tawal a écrit :

comment trouver le bon nom (ou uid) de l'utilisateur "normal" ?

Dans mon cas il s’agissait à chaque fois d’un utilisateur clairement identifié, généralement nouvellement créé par un script.

---

Tawal a écrit :

La solution pkexec commande_root me va bien et me convient mieux je trouve (malgré le timing de la demande de mot de passe).

C’est à mon avis la meilleure approche pour un besoin de privilèges supplémentaires seulement pour une commande donnée. Dans ce cas je n’ai aucune idée de comment forcer une demande d’authentification au début du script, mais je ne serais pas surpris que ce soit possible.

Croutons · 19-02-2023 19:08:15

Hello
Avec sudo y'a un timeout de 15 minutes par défaut
regarde le man sudo

lool_lauris · 19-02-2023 19:30:53

Salut,

Jean-Pierre Pinson a écrit :

Hello, Tawal.
Je t'ai envoyé un message privé

Si ce message privé concerne la demande de Tawal, c'est vraiment dommage de ne pas en faire profiter le forum, et même, ce n'est pas du tout éthique...

Croutons · 19-02-2023 20:20:48

en exécutant en parallèle
un truc du genre

#!/bin/bash

sudo -i &  ls

sudo -i 

ls est bien exécuté en user et on te redemande pas de mot de passe quand tu passes en root du moment que tu es dans les temps

Roland05 · 19-02-2023 21:09:43

lool_lauris a écrit :

Salut,
Jean-Pierre Pinson a écrit :
Hello, Tawal.
Je t'ai envoyé un message privé

Si ce message privé concerne la demande de Tawal, c'est vraiment dommage de ne pas en faire profiter le forum, et même, ce n'est pas du tout éthique...

+1 avec lool_lauris.

Tawal · 19-02-2023 23:04:41

Le message privé ne concerne pas cette discussion

Mais l'accès au chat IRC.

Tawal · 21-02-2023 16:02:28

Re,

J'ai une solution en mode terminal qui permet :
- de lancer le script en tant qu'utilisateur.
- d'avoir la demande de mot de passe afin d'obtenir les privilèges root.
- de garder ces droits pour une utilisation de sudo au moment voulu.

Mais elle est moche

La voici quand même :

#!/bin/bash

# Demande de mot de passe, acquisition des droits root.

sudo -v

# Boucle perpétuelle de maintien des droits (en arrière plan).

while true

do

    sleep 60   # Le temps d'attente est à adapter selon celui de la validité de sudo.

    sudo -v

done &

to_kill=$!

# Assurance de "tuer" la boucle en cas d'arrêt du script.

trap 'kill -15 "$to_kill"' TERM INT ABRT HUP QUIT EXIT

# Le reste du script ici

# Les commandes précédées de sudo s'exécuteront sans demande de mot de passe.

Mais, je répète, cela ne fonctionne que dans un terminal.

Edit:
Condition sine qua non : l'utilisateur doit être sudoers.
Contrairement à pkexec qui demande le mot de passe root à l'utilisateur non-sudoers.

Dernière modification par Tawal (21-02-2023 16:10:54)

Croutons · 22-02-2023 09:23:11

c'est un peu tiré par les cheveux ton truc, comme je le dis dans mon message #6 la validité de sudo est de 15 minutes par défaut
temps qui peut être changé si besoin

Tawal · 22-02-2023 14:34:26

Oui, c'est complètement capilo-tracté.
Et niveau sécurité, pas sûr que ça soit du béton.

Je reste avec ma solution pkexec.

ubub · 22-02-2023 19:28:50

Bonjour,
Vu que c'est un niveau qui me dépasse un peu , par curiosité,
t'as investigué setpriv(1) ... ou...runuser(1) (mais celle là, pas sur)
??

Tawal · 22-02-2023 20:47:51

Je ne vois pas comment faire avec ces commandes.
setpriv semble inapproprié.
runuser n'est utilisable que par root.

Merci tout de même

agp91 · 27-02-2023 15:59:09

Tawal a écrit :

Je ne peux pas autoriser le programme via /etc/sudoers car ses arguments sont variables.
Ce qui rendrait l'autorisation bien trop large si je ne l'affine pas avec ses arguments.

Peux-tu en dire plus STP

Est-ce ton script qui a des arguments trop large ?
Ou la commande à lancer ?
Si c'est la commande est-ce que les arguments sont connus au début du script, au moment ou tu veux demander le pass de root ?

Qu'appelles tu "propre" ?
Un second script root, que tu appelles avec pkexec, qui va donner des droit sudo (sans mot de passe) à un 3em script root qu'il génère, qui contient ta commande. Ce 3em script après avoir lancer ta commande, supprime les droits sudo et s’auto-supprime. Trouve tu ça "propre". ?
Haha, moi en tout cas j'appelle cela plus complexe

agp91 · 27-02-2023 16:15:58

Haha, je que je craignais arrive

agp91 a écrit :

Quand à intervenir... Pour l'instant, il me faut garder l'eau du bain d'ici, pour ne pas m'éparpiller.
Car même si j'ai un schéma qui se précise, pour la refonte, des deux premières pages de cette série de wikis. Je n'ai pas plus.

J'ai maintenant le cerveau qui fuit par ici

Dernière modification par agp91 (27-02-2023 16:22:38)

agp91 · 27-02-2023 17:25:57

agp91 a écrit :

Un second script root, que tu appelles avec pkexec, qui va donner des droit sudo (sans mot de passe) à un 3em script root qu'il génère, qui contient ta commande. Ce 3em script après avoir lancer ta commande, supprime les droits sudo et s’auto-supprime.

Pour que le 3em script ne puisse pas être lancé par l'utilisateur en dehors du script principal (puisqu'il dispose des droit sudo pour le faire), son exécution doit être contrôlé par une clé en dur dans son fichier.
Soit cette clé peut-être générée soit :

Par le script original qui la transmet au script2 appelé par pkexec (soit en argument, soit par une variable fournie lors de son appel : key=$key script2 arg1 arg2...
Ou par script2 qui la retourne au script principal, qui la récupère par la substitution de commande key=$(script2 arg1 arg2...)

Le script d'origine (script1) mémorise la clé dans une variable.
Le script2 inclus alors la clé en dur dans le script3 qu'il génère.
Lorsque que script3 est appelé par script1, il test la clé que lui transmet script1 avec celle qu'il a en dur.
Évidement le script3 doit être en lecture que pour root, afin que personne d'autre puisse lire la clé.
Script3 doit disposer d'une option qui lui permet d’être appelé uniquement pour faire le ménage (supprimer les droits sudo et s'auto-supprimer). Ainsi il peut être appelé par trap dans le script d'origine en cas d’arrêt intempestif.

Dernière modification par agp91 (27-02-2023 19:29:46)

agp91 · 27-02-2023 19:24:59

Pour que cette solution soit "propre", il manque encore trois ou quatre choses :

Que le script1 (le script d'origine) fasse le ménage s'il se termine normalement sans avoir à utiliser le script3 (dans le cas ou la commande qui pose soucis ne soit pas obligatoire dans l'usage de script1)
Un service qui au démarrage contrôle qu"il n'y est pas de script3 (au cas où par exemple l'ordi est été arrêté sans que le script soit fini).
Configurer sudo pour qu'il puisse exécuter, avec les droits root, le script3 hors des répertoire prévus par défaut. Car mettre un exécutable temporaire dans ces répertoires est peut-etre un peu moins "propre" (cela dépend des points vues).
Contrôler que le script1 ne puisse être exécuter plusieurs fois par le même ou un autre utilisateur. Si cela doit pouvoir se faire, il est nécessaire de gérer plusieurs script3 avec des noms différents.

Évidement script1 doit ne pas appartenir à/aux utilisateur(s) et être protégé en écriture. Afin qu'il ne puisse pas être modifié pour injecter du code dans script3 via script2.
Reste un aspect sécurité, ou un tier peut aller chercher, la clé mémorisée par script1 dans variable, directement dans en mémoire (c'est en dehors de mes compétences).

Dernière modification par agp91 (27-02-2023 19:51:38)

Tawal · 27-02-2023 21:36:46

Merci de tes réponses, mais je n'ai rien compris

Il n'est question ici que d'un seul script qui est lancé par un utilisateur normal (sudoers ou non).
Dans ce script, il y a une et une seule commande qui nécessite les droits root.

Le pourquoi je ne peux pas inscrire cette commande dans /etc/sudoers pour mon utilisateur vient que les arguments sont variables (et sont connus au moment de l'appel de la commande root).
N'inscrire que le programme (sans arguments) serait trop large en autorisation (utilisation possible du programme à d'autres desseins).
Je regarde si je ne trouve pas des options du programme (à lancer en root dans le script) que je n'utilise jamais (ou très rarement).
Je pourrais ainsi me servir de /etc/sudoers avec un peu plus de restrictions sur le programme.

La solution de la boucle +sudo -v est une horreur à ne pas utiliser !

Plus je réfléchis à mon problème (quasi solutionné par pkexec), plus je me dis que je dois lancer le script en root, puis de faire les commandes "utilisateur" avec les droits appropriés (edit: cf. ce que disait vv222).

Dernière modification par Tawal (27-02-2023 21:38:49)

agp91 · 28-02-2023 01:25:07

Tawal a écrit :

Merci de tes réponses, mais je n'ai rien compris

Ha, c'est que j'ai mal expliqué alors.
C'est pas grave, si tu es satisfait avec pkexec. Ou si lancer un script sous root, en diminuant les droits sur les ligne de commande de ton script te conviens, alors je ne vais pas insister.

Tawal · 28-02-2023 11:17:23

Je ne suis pour l'instant qu'à moitié satisfait avec pkexec.
Le timing de la demande de mot de passe n'est pas corrélée au lancement du script.
Et il peut y avoir un sacré décalage.

C'est pour ça que lancer le script en root va être pour moi une autre solution plus acceptable que pkexec sur la commande.

Par contre, je me renseigne de ce qu'il est possible de faire exactement dans /etc/sudoers.
Car la commande du script nécessitant les droits root a une option et un seul argument.
Cet argument a une chaîne invariable en début.
Du genre

commande  --option   string$VAR

Edit:
Pour être plus clair, la commande nécessitant des droits root est apt-get.
Elle est utilisée ainsi :

apt-get --asume-yes --quiet install "$VAR"

VAR contient une chaîne invariable en début.
Selon ce qui s'est passé avant dans le script (et ça peut prendre du temps), cette commande est réalisée ou non.
Pour l'instant, j'utilise pkexec sur la commande.

Si tu as d'autres solutions "claires", je suis preneur

Edit2:
Modification des options de la commande apt-get.

Dernière modification par Tawal (28-02-2023 11:35:41)

agp91 · 28-02-2023 14:00:43

Tawal a écrit :

apt-get --asume-yes --quiet install "$VAR"

VAR contient une chaîne invariable en début.

Si tu connais la commande dans son intégralité au début du script, c'est beaucoup plus simple.
Haha; j'aivais envoyé du lourd dés le dépard
Il te suffit de créer un second script qui va te donner les droits sudo (dans /etc/sudoers.d/<fichier>) pour

Lancer apt-get
supprimer le fichier donnant les droits dans /etc/sudoers.d/<fichier>

Nommons ton script, script1
Il te faut créer un second script, nommé ici /path/to/script2 :

#!/bin/bash

cmd1="/usr/bin/apt-get --asume-yes --quiet install $2"

cmd2="/usr/bin/rm /etc/sudoers.d/script1"

echo "$1 $(hostname) = (root) NOPASSWD: $cmd1 , NOPASSWD: $cmd2" > /etc/sudoers.d/script1

J'ai utilisé cmd1 et cmd2 pour plus de clarté, mais ce n'est pas obligatoire.
Je n'ai pas ajouté de contrôle des arguments passés pour etre plus succin.
Le shebang #!/bin/bash est lui obligatoire pour pkexec

Au début de script1 tu exécutes script2 avec pkexec
Il créé le fichier /etc/sudoers.d/script1
Quand tu as besoin tu utilise apt-get avec sudo
Puis tu supprime /etc/sudoers.d/script1 avec sudo

....

pkexec /path/to/script2 $(id -nu) "$VAR"

...

sudo apt-get --asume-yes --quiet install $VAR

sudo rm /etc/sudoers.d/script1

...

Tawal a écrit :

Selon ce qui s'est passé avant dans le script (et ça peut prendre du temps), cette commande est réalisée ou non.

N'oublie pas de supprimer /etc/sudoers.d/script1 avec sudo si la commande n'est pas réalisée.
Ni de l'ajouter dans trap.

Il ne restera plus qu'à faire un petit service lancer au démarrage du PC, pour contrôler si /etc/sudoer.d/script1 existe. Si oui, le supprimer. Au cas où, par exemple, le PC soit éteint brutalement alors que le script tourne.

Dernière modification par agp91 (28-02-2023 15:18:01)

agp91 · 28-02-2023 17:17:16

L'idée du 2em script était plus simple à expliquer.
Mais tu peux aussi mettre son code dans ton script d'origine.
Il sera (le code de script2 ) interprété, que si le script est lancé avec une option particulière (le premier argument), genre --sudo.
Il faut alors étudier en début de script, avec une structure conditionnelle, les arguments qui sont passés au script.

Les arguments transmis à un script sont mémorisés dans les paramètre $1, $2, $3... ${n}.
$0 retourne le chemin absolu relatif du script. $(readlink -f $0) retourn le chemin absolu.
${0##*/} retourne le non du script.

#!/bin/bash

...

sudo_filepath=/etc/sudoers.d/${0##*/}

...

if [ "$1" == --sudo ]

then

  cmd1="/usr/bin/apt-get --asume-yes --quiet install $3"

  cmd2="/usr/bin/rm $sudo_filepath"

  echo "$2 $(hostname) = (root) NOPASSWD: $cmd1 , NOPASSWD: $cmd2" > $sudo_filepath

  exit 0

fi

...

pkexec $(readlink -f $0) --sudo $(id -nu) "$VAR"

...

sudo apt-get --asume-yes --quiet install $VAR

sudo rm $sudo_filepath

...

Lorsque le script est lancé normalement (sans l'option --sudo), le code qui ajoute les droits sudo dans le fichier $sudo_filepath n'est pas exécuté (puisque que l'option --sudo n'est pas transmise).
Quand l'exécution du script arrive à la ligne de pkexec, pkexec relance le script $0 (chemin absolu du script) avec l'option --sudo et pour arguments suivants, les remplacements de $(id -nu) et "$VAR"
Cette seconde instance du script, dont le premier argument est --sudo, exécute le code qui ajoute les droits sudo dans le fichier $sudo_filepath. Et se termine (commande exit 0).
La première instance du script reprend la main et poursuit son exécution.
...

Dernière modification par agp91 (01-03-2023 13:29:17)

Tawal · 01-03-2023 11:23:55

Alors là c'est très clair

Et c'est tout aussi intéressant.
Ta solution (en script séparé ou intégré) me paraît assez solide.
Car même lors du déroulement du script (qui peut prendre du temps avant que ne soit lancée la commande rm /etc/sudoers.d/<script>),
les seules "libertés" laissées ne sont que la commande exacte d'installation et la commande de suppression des droits.

Il faut quand même que je teste car il me semble qu'il faut se déconnecter/reconnecter pour que les changements d'autorisations via /etc/sudoers soient effectifs.

C'est une belle idée à mon sens.

Edit:
C'est ce que je pensais, testé avec ceci :

#!/bin/bash

sudo_filepath=/etc/sudoers.d/${0##*/}

if [ "$1" == --sudo ]

then

  cmd1="/usr/bin/cat $3"

  cmd2="/usr/bin/rm $sudo_filepath"

  echo "$2 $(hostname) = (root) NOPASSWD: $cmd1 , NOPASSWD: $cmd2" > "$sudo_filepath"

  exit 0

fi

pkexec $0 --sudo $(id -nu) "/etc/sudoers.d/${0##*/}"

echo "user=$USER"

sudo cat /etc/sudoers.d/"${0##*/}"

sudo rm $sudo_filepath

Résultat :

$ /home/tawal/Term/test_pkexec.sh

user=tawal

[sudo] Mot de passe de tawal : 

tawal Deb1 = (root) NOPASSWD: /usr/bin/cat /etc/sudoers.d/test_pkexec.sh , NOPASSWD: /usr/bin/rm /etc/sudoers.d/test_pkexec.sh

$

J'ai bien la demande de mot de passe graphique (pkexec) mais les droits ne sont pas encore actifs.
Peut-être existe-t-il un moyen "d'updater" les droits décrits dans /etc/sudoers ?

Dernière modification par Tawal (01-03-2023 11:52:39)

Debian-facile

#1 19-02-2023 11:20:16

[Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#2 19-02-2023 12:32:12

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#3 19-02-2023 13:15:08

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#4 19-02-2023 14:51:34

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#5 19-02-2023 16:48:07

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#6 19-02-2023 19:08:15

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#7 19-02-2023 19:30:53

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#8 19-02-2023 20:20:48

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#9 19-02-2023 21:09:43

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#10 19-02-2023 23:04:41

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#11 21-02-2023 16:02:28

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#12 22-02-2023 09:23:11

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#13 22-02-2023 14:34:26

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#14 22-02-2023 19:28:50

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#15 22-02-2023 20:47:51

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#16 27-02-2023 15:59:09

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#17 27-02-2023 16:15:58

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#18 27-02-2023 17:25:57

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#19 27-02-2023 19:24:59

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#20 27-02-2023 21:36:46

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#21 28-02-2023 01:25:07

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#22 28-02-2023 11:17:23

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#23 28-02-2023 14:00:43

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#24 28-02-2023 17:17:16

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

#25 01-03-2023 11:23:55

Re : [Résolu] Droits root que pour 1 ligne d'un script lancé en USER.

Pied de page des forums