Après une recherche rapide, je pense que c’était pour suivre la recommandation que je viens de retrouver dans le man de readlink :
Note realpath(1) is the preferred command to use for canonicalization functionality.
Alors il faut utiliser realpath ]]>
Dans le script il faut modifier $0 par $(readlink -f $0)
À prendre avec des pincettes, vu que je ne me rappelle plus exactement du pourquoi de ce changement, mais je me rappelle avoir mis à jour mes outils en shell il y a quelques années pour abandonner readlink -f au profit de realpath.
Après une recherche rapide, je pense que c’était pour suivre la recommandation que je viens de retrouver dans le man de readlink :
Note realpath(1) is the preferred command to use for canonicalization functionality.
]]>
peut-être plus dangereuse ...]]>
Tiens voilà avec quoi j'ai testé, je l'ai agrémenté de retours :
Et le retour du lancement du script par son chemin absolu :
Ça fonctionne très bien, on voit la révocation des droits et la demande de mot de passe pour lire /etc/sudoers.d/README.
Super ]]>
Tu remarquera p=$(readlink -f $0), c'est par-ce-que j'ai écris plus haut une clownerie (je corrige) : $0 ne retourne pas le chemin absolu, mais le chemin relatif du script (depuis là où il est lancé). Pkexec apparemment n'aime pas les chemins relatifs.]]>
Résultat :
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 ?]]>
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.
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.
...
]]>
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 :
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
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.]]>
Edit:
Pour être plus clair, la commande nécessitant des droits root est apt-get.
Elle est utilisée ainsi :
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.]]>
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. ]]>
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).]]>
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.]]>