Peut-il y avoir un problème lors de l'utilisation de gedit pour éditer des fichiers système avec 'sudo -H gedit'?

Je suis relativement nouveau sur Ubuntu, j'ai remarqué que dans les réponses sur ce site, lorsque les gens suggèrent de modifier les fichiers système, la commande qu'ils donnent est toujours sudo nanoou sudo vi. Parce que je n'aime pas utiliser les éditeurs de texte basés sur un terminal, j'utilise généralement

sudo -H gedit

au lieu de cela, et jusqu'à présent, cela a parfaitement fonctionné.

Peut-il y avoir un problème avec l'utilisation geditpour éditer les fichiers système ou est-ce que le choix de l'éditeur de texte est purement à la discrétion de la personne? Y a-t-il quelque chose que je devrais garder à l'esprit (comme l'encodage) lors de l'édition de ces fichiers?

Tant que vous l'exécutez correctement, c'est une question de préférence.

Mis à part les différences de fonctionnalités , quel éditeur de texte que vous utilisez est en fait à peu près votre préférence. Cela est vrai même lorsque votre éditeur de texte est un programme graphique comme Gedit . Cela ne veut pas dire qu'il n'y a pas de bonne raison nanoet vimsont souvent recommandés. Les éditeurs de texte basés sur les terminaux aiment vim(ou au moins une vicommande) et nanosont disponibles même lorsqu'il n'y a pas d'interface graphique et même sur la plupart des systèmes très minimes et cassés ; ils ont une tradition derrière eux (si vous êtes partisan de ce genre de chose); ils peuvent être exécutés dans le même terminal dans lequel d'autres tâches sont effectuées; ils s'intègrent automatiquement dans les workflows des utilisateurs du multiplexeur terminal ; et ils sont plus susceptibles d'être disponibles que toutéditeur de texte graphique particulier , même Gedit, même sur Ubuntu (qui a plusieurs saveurs ).

Ce n'est pas tout. Si vous souhaitez modifier des fichiers système, une approche consiste à exécuter votre éditeur en tant que root. Ce n'est pas la seule approche, et il y a quelques arguments contre (voir ci-dessous), mais c'est une approche courante. Si vous adoptez cette approche et utilisez un programme graphique comme éditeur, vous devez prendre soin de l' exécuter de manière à ce que ce $HOMEsoit le répertoire personnel de root plutôt que le vôtre , ce qui ajoute une nouvelle couche de tracas et de complexité. Mais vous le faites déjà; vous courez sudo -H gedit, ce qui est l' un des moyens raisonnables . Pourtant, cette complexité est une autre raison pour laquelle les gens ont tendance à suggérer des éditeurs non graphiques.

Les programmes graphiques sont souvent plus compliqués que les programmes non graphiques. Avoir plus de choses exécutées en tant que root est généralement mauvais, car il y a plus de façons dont les choses pourraient mal tourner, y compris en raison de bogues possibles, y compris par accident. (Les éditeurs de texte non graphiques tels que vimsont également assez sophistiqués et sont souvent configurés pour exécuter de nombreux programmes externes pour effectuer diverses tâches.)

Outre l'exécution de l'éditeur en tant que root, une autre approche générale consiste à modifier un fichier que l'éditeur est capable de modifier même lorsqu'il s'exécute en tant qu'utilisateur (non root), de sorte que les modifications apportées au fichier soient propagées vers le fichier appartenant à la racine que vous souhaitez changer. Cela semble abstrait, car les détails varient considérablement. Deux grandes approches concrètes suivent.

sudoedit

Une façon assez ancienne de le faire est sudoedit(documentée dans la même page de manuel quesudo ). Par défaut, sudoeditutilise l'éditeur de texte par défaut , qui n'est généralement pas - et ne devrait pas être - un programme graphique. Mais vous pouvez lui dire d'utiliser un éditeur à travers les SUDO_EDITOR, VISUALou les EDITOR variables d'environnement , qu'il consulte dans cet ordre. Ainsi, vous pouvez exécuter:

VISUAL=gedit sudoedit filename

Remplacez filenamepar un chemin relatif ou absolu vers votre fichier.

Cela crée une copie temporaire du fichier que vous souhaitez modifier. La copie vous appartient, pas à root (ou à qui que ce soit le propriétaire d'origine). Il ouvre l'éditeur de texte et vous pouvez modifier la copie temporaire. Lorsque vous fermez l'éditeur de texte, sudoeditvérifie si vous avez réellement apporté des modifications. Si vous l'avez fait, il copie modifié copie temporaire de retour à l'original.

Bien qu'il sudoeditfonctionne avec des éditeurs graphiques, il est également utile pour les éditeurs basés sur des terminaux. Dans les deux cas, les pistes de l' éditeur de texte que vous, il a donc votre configuration, et d' autres actions que vous effectuez dans ce autre que les modifications apportées à ce fichier sont effectuées par vous, qui offre un peu de protection contre certains types d'erreurs.

Vous pouvez définir l'une de ces variables d'environnement de manière persistante si vous le souhaitez. SUDO_EDITORest peut-être le meilleur car il est utilisé pour moins d'autres choses. Cependant, si vous le définissez sur gedit, gardez à l'esprit que des commandes comme ne fonctionneront pas lorsqu'aucune interface graphique n'est disponible, comme c'est souvent (mais pas toujours ) le cas dans une console virtuelle ou via SSH .sudoedit filename

Le backend d'administration GVFS

Une autre façon plus récente de procéder consiste à ouvrir le fichier via son admin://chemin GVFS plutôt que son chemin traditionnel de style Unix. Merci à pomsky de m'avoir appris cela. Tout comme il existe des chemins GVFS pour éditer des fichiers qui, à d'autres égards, ne sont pas dans un endroit pratique pour être édités - par exemple parce qu'ils se trouvent sur une machine distante à laquelle vous êtes connecté via SSH - GVFS prend en charge les admin://chemins pour éditer des fichiers vous ne possédez pas.

Ceci est conceptuellement similaire au fait sudoeditque vous exécutez votre éditeur en tant que vous-même et que le fichier que l'éditeur voit est quelque chose qu'il est autorisé à modifier. Si vous tentez d'ouvrir le fichier, vous devez vous authentifier; ce n'est pas un moyen magique de contourner les restrictions de sécurité habituelles.

gedit admin:///path/to/filename

Il /path/to/filenamedoit y avoir un chemin absolu vers le fichier, en commençant par /. Il y a donc trois /caractères après admin:.

Encodages et autres éléments théoriquement affectés par la configuration de l'éditeur

L'encodage d'un fichier n'est pas vraiment affecté par le fait que l'éditeur que vous utilisez soit graphique ou non. Certains éditeurs, comme vim, peuvent même fonctionner graphiquement (la gvimcommande) ou non graphiquement (la vimcommande). La réponse simple à votre question sur les encodages est que vous n'avez pas à vous en préoccuper. C'est assez proche de la vérité que vous n'avez vraiment pas besoin de lire le reste de cette réponse.

Dans les versions actuelles (et passées) d'Ubuntu, les commandes aiment sudo nanoet sudo vimexécutent ces éditeurs en tant que root mais sont $HOMEtoujours définies dans votre répertoire personnel. Cela signifie que les éditeurs utiliseront par défaut votre configuration plutôt que la configuration de root. S'il y a quelque chose dans votre configuration de ces éditeurs (ou dans un programme qu'ils exécutent pour faire une partie de leur travail, comme git) concernant les encodages ou les fins de ligne , il sera suivi. Avec , cela n'arrivera pas.sudo -H editor

Certaines personnes utilisent nu sudo(c'est-à-dire sans -iou -H) aux éditeurs parce qu'elles le veulent. Mais vraiment, vous devriez y réfléchir à deux fois. Non seulement vous pouvez atteindre cet objectif plus proprement avec une méthode comme sudoedit, il y a d'autres inconvénients des commandes comme sudo nanoet sudo vim:

• Si la configuration de votre éditeur entraîne l'exécution de quelque chose, celui-ci est exécuté en tant que root. Pour les éditeurs sophistiqués comme celui-ci vim, cela peut entraîner l'exécution d'un certain nombre de codes non triviaux en tant que root. Comme mentionné ci-dessus, avoir moins de code exécuté en tant que root est généralement bon et c'est l'un des arguments contre l'exécution d'éditeurs graphiques en tant que root.

  Si votre vimconfiguration a de nombreux plugins - par exemple, pour effectuer une analyse statique du code source que vous tapez - et n'a pas, moins exécute trucs de racine en tant que root avec que . (Encore moins s'exécute en tant que root avec , mais vos plugins fonctionnent toujours!) Ceci est distinct du fait que votre éditeur soit graphique ou non.sudo -H vim filenamesudo vim filenameVISUAL=vim sudoedit filename

• Si la configuration de votre éditeur est cassée et vous empêche de modifier facilement les fichiers, la correction peut être encore plus compliquée, car elle s'applique également à root. Ce n'est qu'un problème, pas un problème difficile à résoudre.

• Les commandes comme sudo vimont un peu le même problème que la commande (mal avisée!) sudo gedit. Si vous exécutez un éditeur comme vimroot mais sans réinitialiser $HOME(comme sudo -Het le sudo -iferait), et qu'il crée des fichiers de configuration pour lui - même , ces fichiers de configuration résideront dans votre répertoire personnel mais ils appartiendront à root, et votre configuration peut être quelque peu cassée lorsque vous exécutez l'éditeur plus tard en tant que vous-même.

  Eh bien, cela ressemble beaucoup à ce problème! La raison pour laquelle c'est moins important qu'avec les applications graphiques est que l'éditeur démarre généralement toujours, les messages d'erreur sont généralement plus faciles à comprendre, vous pouvez généralement comprendre quels fichiers spécifiques sont affectés beaucoup plus facilement et la rupture est généralement limitée à ce seul programme. (Les programmes graphiques utilisent des fichiers de configuration à plusieurs endroits.) De plus, contrairement aux éditeurs graphiques, les utilisateurs qui n'utilisent que par hasard un éditeur de texte et ne modifient pas délibérément sa configuration sont peu susceptibles de rencontrer ce problème.

Encore une fois, vous pouvez utiliser la configuration de l'éditeur de votre propre compte d'utilisateur tout en évitant les problèmes d'autorisations en utilisant sudoeditou, à partir du bureau, en démarrant l'éditeur normalement mais en accédant au fichier via un admin://chemin.

Enfin, notez que le comportement mentionné ci-dessus de sudoquand -Hou -iest passé est en fait prévu de changer dans une future version d'Ubuntu (comme il l'a déjà fait, il y a des années, dans la plupart des systèmes d'exploitation de type Unix qui utilisent sudo). Le comportement a déjà changé dans Ubuntu 19.10 , qui est la version de développement à ce jour.

Pour répondre à votre question: En général, l'utilisation d'un éditeur GUI ne sera pas un problème en plus d' geditêtre très lente pour les gros fichiers.

Mais pour les programmes GUI que vous utiliseriez pkexecou gksuau lieu de sudo. Vous devrez peut-être configurerpkexec avant que cela fonctionne.

pkexec gedit

ou pour les anciennes versions d'Ubuntu (par exemple 16.04), vous pouvez utiliser:

gksu gedit

(Bien que vous puissiez essayer de meilleurs éditeurs GUI, par exemple geany;-))