{{tag>Bionic Xenial tutoriel BROUILLON}}
----

====== Problématiques liées à l'édition des fichiers système via une application graphique ======

Ce tutoriel vient en complément tutoriel [[tutoriel:comment_modifier_un_fichier|Comment modifier un fichier]], du mini tuto [[:sudo|droits de super utilisateur]] et du tutoriel plus étendu [[tutoriel:effectuer_des_taches_en_super_utilisateur|sudo : effectuez des tâches administratives]]. Il vise à expliciter les questions qui reviennent le plus souvent: //Comment éditer un fichier avec les droits d'admin?// et //Pourquoi on ne doit pas utiliser// ''sudo gedit''?

===== Rappel sur les niveaux de droit =====

Pour des raisons de sécurité, un utilisateur lambda ne peut pas modifier tous les [[:arborescence|fichiers]] du système. Généralement il a simplement accès à ce qui est situé dans le dossier ''/home/utilisateurlambda''. 

Cela présente également l'avantage que si plusieurs personnes utilisent le même ordinateur, il n'y a pas de risque que l'un modifie les fichiers de l'autre, soit par action délibérée, soit par effet de bord, par exemple si suite à un bug quelconque l'un des logiciels utilisés essaie d'écrire là où il ne devrait pas.

Dans le même ordre d'idée, il n'y a pas non plus de risque de modifier par mégarde des fichiers nécessaires au bon fonctionnement d'Ubuntu, car ces derniers sont gérés par un utilisateur dédié: ''root''. Mais du coup lorsqu'on a vraiment besoin de modifier un fichier système, il faut se faire passer pour l'utilisateur root afin d'exécuter des commandes non plus en tant que simple utilisateur, comme c'est le cas par défaut, mais en tant qu'administrateur. C'est le rôle de la commande [[:sudo|sudo]]

===== Rappel sur les contraintes liées à l'utilisation d'une application graphique en administrateur =====
==== Liées au risque d'écrasement des fichiers utilisateur ====
Prenons l'exemple de l'utilisateur //toto// qui va exécuter un commande de type ''sudo application''. Il faut bien comprendre que l'application est lancée en tant qu'utilisateur //root// avec l'environnement de l'utilisateur //toto//. En particulier avec ''HOME=/home/toto'' et toutes les autres variables d'environnement propres à toto. En conséquence si l'application écrit dans des fichiers d'historique, de configuration, etc, toto va se retrouver avec ces fichiers dans son répertoire ''/home/toto'' qui appartiendront désormais à l'utilisateur //root//. La prochaine fois qu'il lancera l'application il risque donc d'avoir un message d'erreur indiquant qu'il est impossible de lire/charger telle ou telle ressource.

Cela peut aller jusqu'à l'impossibilité d'ouvrir une session lorsque le fichier ~/.Xauthority devient la propriété de root. Et ce n'est pas un problème rare, le forum regorge de cas d'utilisateurs qui ont étourdiment utilisé //sudo// pour lancer une application graphique qui n'avait pas été prévue pour.

==== Liées au type d'environnement graphique ====
Parmi toutes les [[:variantes|variantes d'Ubuntu]], la méthode d'administration en ligne de commande est toujours la même. Par contre dés que l'on souhaite administrer via une application graphique, les contraintes varient fortement. Par exemple, suivant que vous utilisez une distribution basée sur [[:xorg|X.org]] ou sur [[:wayland|Wayland]]. Ou suivant que votre variante est basée sur [[:gnome|GNOME]] ou [[:kde|KDE]]. 

Par défaut le présent wiki partira toujours de l'hypothèse que vous vous basez sur la dernière [[:lts|version maintenue à long terme (LTS)]] d'Ubuntu, il vous revient d'adapter en fonction de votre variante. 

===== Méthode canonique =====

==== En ligne de commande ====
La manière recommandée de faire est d'utiliser un éditeur en console comme [[:nano|Nano]] via une commande de type:

   sudo nano /chemin/absolu/vers/fichier

Cela peut paraitre rebutant de prime abord pour un débutant, mais nano est un éditeur très simple et très facile à prendre en main, et le fait de ne pas recourir un un logiciel graphique simplifie énormément le processus.

==== via une application graphique ====
Se reporter au tutoriel [[tutoriel:comment_modifier_un_fichier|Comment modifier un fichier]]. Un exemple:

   gedit admin:///chemin/absolu/vers/fichier

===== Méthodes déconseillées =====
Au travers des forums vous pourrez tomber sur des manières alternatives de faire, au rang desquelles:

  * ''sudo gedit /chemin/vers/fichier'' (déconseillé de même que toute utilisation de sudo pour lancer une application graphique)
  * ''sudo -H'', ''sudo -s'' ou ''sudo -i'' (le moins mauvaise des trois) pour passer en utilisateur root, suivit de ''gedit /chemin/vers/fichier'' (cette méthode est moins mauvaise que ''sudo gedit'' mais elle ne résout pas tous les problèmes)
  * ''pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit'' (techniquement valide si ce n'est que c'est identique à la méthode canonique, en plus compliqué)
  * ''gksudo gedit'' (ou ''kdesudo kate'' pour les utilisateurs de [[:kubuntu|Kubuntu]]): ça peut encore marcher sur des distributions encore basées sur [[:xorg|X.org]], à condition d'installer les paquets correspondants, mais dans le cas d'[[:bionic|Ubuntu 18.04 LTS]] et suivantes ça sera complètement inopérant.
  * méthode basée sur ''xhost'' (techniquement valide, mais inutilement complexe)

Toutes ces méthodes sont déconseillées soit du fait des problèmes qu'elles peuvent poser par effet de bord, soit du fait de leur trop grande complexité de mise en œuvre comparativement à la méthode canonique

===== Méthodes alternatives =====
==== Utilisation d'une application graphique spécifique ====
Certaines applications sont prévues spécifiquement pour permettre d'administrer graphiquement le système. Avec ces applications vous n'aurez rien de spécial à faire, elles vous demanderont le mot de passe administrateur lorsqu'elles en auront besoin. C'est par exemple le cas de la [[:logitheque|]].

==== Modification en deux temps ====
Une alternative parfaitement valide consiste à procéder en deux temps:
  - Lancez un éditeur de texte et ouvrez le fichier à modifier en lecture seule, puis enregistrez-en une copie quelque part, par exemple dans ''/tmp'' et faites-y les modifications souhaitées.
  - puis déplacez le fichier obtenu via [[:commande_shell#manipulation|mv]] à l'emplacement souhaité

Par exemple supposant que vous souhaitiez modifier le fichier ''/etc/apt/sources.list'', vous lancez gedit, vous enregistrez une copie dans ''/tmp/sources.list'', vous faites vos modifications, et enfin vous déplacez le résultat obtenu via ''sudo cp /tmp/sources.list /etc/apt/sources.list''

==== Sécurisation de l'environnement graphique ====
<note warning>Cette méthode tient du hack pour simuler une utilisation dans serveur X, elle est montrée davantage pour illustrer les problématiques liées à cette démarche que dans le but d'être utilisée. Notez qu'elle suppose que [[:xorg|X.org]] soit installé en parallèle de [[:wayland|Wayland]]</note>
Pour les indécrottables du //sudo gedit//. Attention à bien suivre toutes les étapes car le moindre oubli peut être fatal.
  - (In)Sécurisation de la session graphique en autorisant des utilisateurs tiers à accéder à votre session wayand: ''xhost +si:localuser:root'' 
  - Passage en utilisateur root, mais en protégeant votre répertoire //HOME//: ''sudo -H''
  - Lancement de votre application graphique (en root donc, attention à ce que vous faites!): ''gedit /chemin/vers/fichier''
  - Fermeture de votre application graphique lorsque vous avez terminé votre manip
  - Retour à votre user nominal dans le terminal: ''exit''
  - Rétablissement de la session graphique originale: ''xhost -si:localuser:root''

<note>Si l'utilisation de ''sudo -H'' vous permet de protéger votre //HOME//, l'implication est que c'est le //HOME// de l'utilisateur //root// qui sera affecté par d'éventuels effets de bord. </note>

===== Conclusion =====

Normalement vous devriez avoir compris pourquoi il est dangereux de se risquer à utiliser le mot clé //sudo// pour lancer une application graphique, et quels sont les risques afférents. Il est bien compréhensible que vous souhaitiez éviter au maximum l'usage de la ligne de commande sur une distribution grand public comme Ubuntu. Cependant dans le cas particulier de l'administration du système en général, et de l'édition des fichiers de configuration en particulier, la manière dont le système est conçu fait qu'il sera toujours plus simple et moins risqué de procéder en ligne de commande plutôt que de se compliquer (énormément) la vie pour réussir à faire graphiquement en se donnant beaucoup de mal une opération qui est simplissime dans le terminal.

===== Voir aussi =====

  * [[https://forum.ubuntu-fr.org/viewtopic.php?pid=22021343#p22021343|Discussion relative à cette problématiqe]] sur le forum ubuntu-fr
  * [[https://askubuntu.com/questions/961967/why-dont-gksu-gksudo-or-launching-a-graphical-application-with-sudo-work-with-w|Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?]] (en)


{{topic>:  sudo}}

----
//Contributeurs principaux : [[:utilisateurs:aldian]].//