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

Ce tutoriel vient en complément tutoriel Comment modifier un fichier, du mini tuto droits de super utilisateur et du tutoriel plus étendu 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?

Pour des raisons de sécurité, un utilisateur lambda ne peut pas modifier tous les 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

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.

Parmi toutes les 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 X.org ou sur Wayland. Ou suivant que votre variante est basée sur GNOME ou KDE.

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

La manière recommandée de faire est d'utiliser un éditeur en console comme 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.

Se reporter au tutoriel Comment modifier un fichier. Un exemple:

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

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): ça peut encore marcher sur des distributions encore basées sur X.org, à condition d'installer les paquets correspondants, mais dans le cas d'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

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.

Une alternative parfaitement valide consiste à procéder en deux temps:

1. 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.
2. puis déplacez le fichier obtenu via 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

Pour les indécrottables du sudo gedit. Attention à bien suivre toutes les étapes car le moindre oubli peut être fatal.

1. (In)Sécurisation de la session graphique en autorisant des utilisateurs tiers à accéder à votre session wayand: xhost +si:localuser:root
2. Passage en utilisateur root, mais en protégeant votre répertoire HOME: sudo -H
3. Lancement de votre application graphique (en root donc, attention à ce que vous faites!): gedit /chemin/vers/fichier
4. Fermeture de votre application graphique lorsque vous avez terminé votre manip
5. Retour à votre user nominal dans le terminal: exit
6. Rétablissement de la session graphique originale: xhost -si:localuser:root

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.

• Discussion relative à cette problématiqe sur le forum ubuntu-fr
• Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland? (en)

Contributeurs principaux : aldian.