Quelles sont les mauvaises choses qui se produisent lorsque gedit est utilisé avec sudo?
Je lis cette réponse expliquant que "parfois" root peut posséder quelque chose dans le répertoire _/home/$USER_.
Quelqu'un peut-il donner un exemple comment le prouver? Donnez juste un cas de test quand quelque chose de vraiment grave se produit, quand je cours
_Sudo gedit /etc/rc.local
_éditer le fichier et sauvegarder.
J'ai eu beaucoup de votes négatifs essayant d'aider OP et les commentaires ont été inondés en disant que c'est un crime de courir avec gedit avec Sudo.
Quelqu'un peut-il donner un exemple réel?
J'ai clairement expliqué pourquoi cette question n'est pas un doublon. Il n'y a pas de réponse spécifique à gedit à la question liée.
Et il est important d'expliquer pourquoi _Sudo gedit_ largement utilisé est mauvais, ou pas vraiment, etc.
En ce qui concerne _Sudo gedit_, rien de grave, juste une mauvaise pratique, en particulier ces derniers temps. Combien plus difficile serait-il de suggérer _Sudo -H gedit_?
-H_, _--set-homeDemander à la stratégie de sécurité de définir la variable d'environnement HOME sur le répertoire de base spécifié par l'entrée de la base de données de mots de passe de l'utilisateur cible. Selon la stratégie, il peut s'agir du comportement par défaut.
Que fait-il ?
Vous obtenez quelques fichiers appartenant à la racine dans votre dossier personnel. Un (_recently-used.xbel_) reviendra probablement à l'utilisateur. Cela peut arriver lorsqu'un fichier est supprimé et recréé. Pour voir ce que _Sudo gedit_ a changé, exécutez _find ~ -user root -group root_ et voyez ce qui est renvoyé. Par défaut, cela ne devrait être rien.
Avec cette commande, vous pouvez voir quelques fichiers appartenant à root. L'une serait une nouvelle _.file_, _.gvfs_ et, tôt ou tard, une racine appartenant à la racine _~/.cache/dconf_ et la susdite _recently-used.xbel_.
Donc, pas de choses "le ciel est défaillant", mais quand même. À présent, il a été rapporté que l'utilisation continue causait d'autres problèmes, mais ne revendiquait pas ce que je ne vois pas ici.
Notez également qu'à partir de 13h10, un _Sudo gedit_ utilisera la configuration gedit de l'utilisateur plutôt que la configuration gedit de root. Encore une fois juste une mauvaise pratique alors pourquoi continuer à le faire ou suggérer à d’autres de le faire?
C'est peut-être un fantasme, mais plusieurs personnes disent la même chose:
Pourquoi devrais-je utiliser gksudo pour les applications Gtk au lieu de sudo?
Cependant, il arrive parfois que les effets secondaires soient aussi légers que des extensions de Firefox qui ne collent pas ou aussi extrêmes que de ne plus pouvoir se connecter car les autorisations sur votre .ICEauthority ont changé.
Supposons que vous exécutiez gedit (un éditeur de texte graphique) en tant que root. Si vous exécutez Sudo gedit, HOME continuera de pointer vers votre répertoire personnel, même si le programme est exécuté en tant que root. Par conséquent, gedit écrira les fichiers de configuration en tant que root dans votre répertoire personnel. Il en résultera parfois que les fichiers de configuration appartiendront à root et seront donc inaccessibles pour vous (lorsque vous exécuterez le programme ultérieurement en tant que tel et non en tant que root).
Comment exécuter un programme graphique en tant qu’utilisateur différent (Debian)?
Tout d’abord, n’utilisez pas Sudo ou su pour modifier les utilisateurs afin d’exécuter un processus graphique, sinon vous risquez d’avoir des problèmes plus tard (le changement de propriétaire de ~/.ICEauthority est un problème notable). Au lieu de cela, créez un raccourci qui utilise la commande suivante:
Eh bien, pour être tout à fait honnête, la plupart du temps, ce n’est pas le cas. Pour de nombreuses applications, vous pouvez les exécuter de manière inappropriée: utilisez Sudo pour des applications graphiques et ne constatez aucun effet secondaire indésirable.
...
Ces erreurs se produisent car parfois, lorsque
Sudolance une application, celle-ci démarre avec les privilèges root mais utilise le fichier de configuration de l'utilisateur.
Alors testons-le.
2 nouvelles boîtes virtuelles. Ubuntu 14.04. Ne jamais exécuter Firefox sur eux. Que se passera-t-il lorsque j'exécuterai la commande Sudo firefox?
tim@Hairy14CVB:~$ Sudo firefox
(process:4857): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
...
[email protected]:2192:13
C'est le même (ou au moins très similaire) pour les deux boîtes virtuelles. Alors que Firefox était en cours d’exécution, j’ai installé une extension youtube, en vedette. Ensuite, j'ai fermé Firefox et vérifié la sortie.
tim@Hairy14CVB:~$ ls -la .ICEauthority
-rw------- 1 tim tim 1336 Jun 4 21:31 .ICEauthority
Eh bien, .ICEauthority tout va bien! Pourtant...
tim@Hairy14CVB:~$ ls -la | grep root
drwxr-xr-x 3 root root 4096 Jun 1 20:49 ..
drwx------ 3 root root 4096 Jun 5 22:41 .dbus
drwx------ 4 root root 4096 Jun 5 22:41 .mozilla
Trois éléments de mon dossier de départ (/home/tim/) appartiennent à root (.., .dbus et .mozilla). C'est le même (ou au moins très similaire) pour les deux boîtes virtuelles.
Alors, est-ce important? Je n'étais pas sûr, alors j'ai couru Firefox, comme ceci:
tim@Hairy14CVB:~$ firefox
(process:4959): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Error: Access was denied while trying to open files in your profile directory.
Et cette erreur laide:
Pour la sortie complète du terminal (y compris firefox babble), voir ces deux pâtes, ici et ici .
En passant, je peux toujours utiliser Firefox en tant que root. Mais maintenant, plus de fichiers ont été modifiés:
tim@Hairy14VB:~$ ls -la | grep root
drwxr-xr-x 4 root root 4096 Jun 3 19:46 ..
drwx------ 3 root root 4096 Jun 5 22:55 .Adobe
drwx------ 3 root root 4096 Jun 5 22:40 .dbus
drwx------ 3 root root 4096 Jun 5 22:55 .macromedia
drwx------ 4 root root 4096 Jun 5 22:40 .mozilla
Est-ce parce que j'ai téléchargé une image sur imgur.com? Pas certain.
Comment ai-je résolu ce problème? chown. Je ne le comprends pas, mais Internet a dit de le faire, et c’est une boîte virtuelle alors yolo.
Sudo chown -R tim:tim /home/tim/
Et ça a réglé le problème. Maintenant, la sortie est juste le fichier ..:
tim@Hairy14VB:~$ ls -la | grep root
drwxr-xr-x 4 root root 4096 Jun 3 19:46 ..
Et c'est la même chose sur mon ordinateur actuel. Oh, et sur ma boîte virtuelle Kubuntu:
tim@Hairy14VB:~$ ls -la | grep root
drwxr-xr-x 3 root root 4096 May 16 14:10 ..
Sur lequel je n'ai même jamais lancé de commande Sudo. Donc tout va bien. Il suffit de ne pas exécuter Sudo sur une application graphique.
Test final: exécutez-le avec les drapeaux -H et -i:
Sudo -H firefox
et
Sudo -i firefox
Et bonne nouvelle! Reste que la seule "chose" racine est ... Et je peux exécuter firefox sans racine.
OP veut que je parle de Gedit.
J'ai couru
Sudo gedit
Puis installé des plugins aléatoires. C'était la sortie:
tim@Hairy14VB:~$ ls -la | grep root
ls: cannot access .gvfs: Permission denied
drwxr-xr-x 4 root root 4096 Jun 3 19:46 ..
Notez que je ne peux même pas voir la propriété de .gvfs alors j'ai fait ceci:
tim@Hairy14VB:~$ Sudo ls -la | grep root
drwxr-xr-x 4 root root 4096 Jun 3 19:46 ..
dr-x------ 2 root root 0 Jun 6 10:05 .gvfs
Donc, exécuter Sudo gedit change un fichier de mon répertoire personnel en root.
Je peux toujours ouvrir gedit, mais cette fois, je sors des ordures:
(gedit:7422): Gtk-WARNING **: Attempting to read the recently used resources file at `/home/tim/.local/share/recently-used.xbel', but the parser failed: Failed to open file '/home/tim/.local/share/recently-used.xbel': Permission denied.
Et cela suggère qu'il existe un autre fichier (~.local/share/recently-used.xbel) qui a été modifié. Je pense que ceci est la liste des fichiers récemment utilisés et (bonne chance) je n'ai plus ma liste de fichiers récemment utilisés:
Il devrait y avoir un fichier appelé output2.txt.save2.