[Résolu] sudo gedit réagit mal...

Jarodd · Le 23/02/2018, à 20:22

Bonjour,

Je tombe sur ce sujet par hasard, et je vois qu'il ne faut pas faire sudo gedit (ici ou dans la doc).
C'est très bien de le dire et répéter, mais je n'ai pas compris pourquoi !

nam1962 · Le 23/02/2018, à 21:16

Parce que ça torpille les droits des paquets appelés.
L'utilisation de sudo peut entraîner une prise de propriété des paquets par root.
moko138 m'a souvent tancé sur le sujet.

moko138 a écrit :

Il semble que ce soit de loin la cause la plus fréquente du passage soudain en lecture seule de partitions internes ou externes

Mais il l'a lui même découvert dans la douleur ! https://forum.ubuntu-fr.org/viewtopic.php?id=1189501

Dernière modification par nam1962 (Le 23/02/2018, à 21:19)

Jarodd · Le 23/02/2018, à 21:17

Merci nam !

nam1962 · Le 23/02/2018, à 21:20

Il n'empèche que devoir solliciter pour gedit

gedit admin://l_URI_concernée

est trrrès baroque !!!

Comme le fait de changer de chapelle régulièrement (gksudo a été installé par défaut, puis pas recommandé, puis pas installé, puis parfois installé par défaut... Roshan connait p'tet l'opinion de Linus et de Mark sur ces errements )

Dernière modification par nam1962 (Le 23/02/2018, à 21:31)

erresse · Le 24/02/2018, à 10:19

Bonjour,

L'effet nocif de "sudo gedit" (ou autre application graphique) souvent remarqué, c'est qu'après une telle commande, l'utilisateur ne peut plus s'identifier lorsqu'il ouvre sa session. Alors, c'est la panique à bord et on vient interroger le forum pour se sortir du caca.

La raison, c'est que cette opération modifie (parfois, ce n'est pas systématique) les droits et propriété du fichier .Xauthority situé dans le répertoire de l'utilisateur pour l'attribuer à "root". Du coup, l'utilisateur ne peut plus ouvrir / mettre à jour ce fichier lorsqu'il ouvre sa session et il se voit refuser l'accès.

Généralement, il suffit de se logger en console et de soit remettre le fichier .Xauthority en conformité, soit supprimer le fichier qui sera normalement recréé lors de la prochaine ouverture de session graphique.

Et, pour rejoindre le point de vue de nam1962, je ne comprend pas très bien pourquoi le paquet "gksu" n'est pas installé par défaut comme avant, puisque dans un système *buntu, "sudo" est nécessaire et, par conséquent, "gksudo" ou "kdesu" également pour lancer des applications graphiques avec les droits "root" (n'en déplaise aux puristes qui ne conçoivent pas qu'on effectue des tâches d'administration en mode graphique).

Foromus · Le 24/02/2018, à 11:39

Bonjour à tous,

A voir les développements, il me semble avoir ouvert un sujet intéressant.
Au passage, merci pour la volée de bois vert, il est vrai que "j'en ai ramassé" pas mal depuis que je suis passé sous Linux (au passage, migrer sous Linux, "faut en vouloir"...).
J'essaie de ne pas rester trop borné, comme dit un autre intervenant, je suis un utilisateur basique, j'essaie juste de comprendre et éviter de faire de grosses bêtises, et compte-tenu de ce que j'ai dit ci-dessus, j'évite autant que faire se peut, de demander, surtout sur ce forum malgré le nombre considérables d'aides que j'ai pu recevoir et dont je suis très reconnaissant à l'endroit des aidants.
En clair et en conclusion : ne plus utiliser sudo gedit, il y a des risques, on a dit lesquels et pourquoi. J'en prends note. Conséquemment, il est recommandé d'utiliser sudo nano (sudo nano /etc/hosts dans ma question), et de la façon dont je l'ai appréhendé, il va falloir que je fasse des essais discrets sur un fichier test avec nano.

Et pour info, un débutant n'est pas censé modifier son fichier hosts, c'est un travail d'adminstrateur.

Peut-être... Je suis débutant depuis la version 8 ou 10 d'ubuntu, je ne sais plus, et je continue et persiste à débuter...
Modifier le fichier hosts n'a rien de rebutant, d'après ce que j'ai compris, ça permet de maîtriser un peu mieux son navigateur, avec avantages et inconvénients, il faut parfois retourner dans le fichier quand l'url d'un site a changé car alors, il devient inaccessible (mais on s'en rend compte rapidement).

Merci à tous pour votre aide bienveillante et votre courtoisie, croyez bien que j'y suis très sensible.
Ce sujet est résolu (pour moi)

krodelabestiole · Le 24/02/2018, à 13:14

Foromus a écrit :

Modifier le fichier hosts n'a rien de rebutant, d'après ce que j'ai compris, ça permet de maîtriser un peu mieux son navigateur, avec avantages et inconvénients, il faut parfois retourner dans le fichier quand l'url d'un site a changé car alors, il devient inaccessible (mais on s'en rend compte rapidement).

perso les seuls moments où je vais éditer un fichier hosts c'est pour mon activé de développeur web, ou pour installer du warez sous windows.
pourquoi tu veux le modifier exactement ?

Foromus · Le 24/02/2018, à 14:12

krodelabestiole a écrit :

pourquoi tu veux le modifier exactement ?

Bonjour,

Un jour, j'ai lu quelque part que, quand on voulait aller sur un site, il fallait taper l'url dans la barre adéquate, ensuite, on m'a expliqué que, en informatique, le système ne savait pas lire "www.machin.fr", qu'il ne savait que lire "123.45.etc" et qu'on appelle "adresse IP". Comme il fallait une traduction pour passer du premier au second, on m'a expliqué que, dès la demande première formulée, le système allait consulter un serveur spécial (DNS si je me souviens bien) et que celui-ci renvoyait l'adresse IP qui était enfin sollicitée. On m'a aussi expliqué que cette visite des DNS n'était peut-être pas forcément innocente, et en tous les cas, cela prenait un peu de temps (négligeable en fait). Pour continuer, j'ai appris que le fichier hosts était d'abord consulté avant toute démarche, et dans le cas où il trouvait l'IP concernée, il y allait directement, et si il ne la trouvait pas, il revenait sans rien, mais que si l'IP mentionnée était erronée, l'accès était bloqué. J'ai trouvé la chose intéressante, et j'ai complété mon fichier hosts, pas n'importe comment, mais en suivant les conseils avisés de personnes œuvrant sur des sites ouverts à la sécurité informatique, je n'ai bien entendu, rien inventé ! Et j'agis toujours avec grande prudence, ce qui ne me met pas à l'abri d'une erreur, malgré mon souci de gérer mon système, peut-être pas au mieux mais au moins mal.
Voilà, dans mon hosts, j'ai la liste de la plupart des sites que je visite régulièrement (dont celui-ci) et si ça coince, je mets un " # " en début de ligne, et j'essaie de trouver la nouvelle IP.
Maintenant, si on me prouve que tout cela est une vaste fumisterie, je m'incline devant la science, je passe toutes mes lignes à #, et je marche à la classique !

bruno · Le 24/02/2018, à 14:27

Bon on s'éloigne totalement du sujet d'origine…
L'usage que tu fais de ton fichier hosts est à mon avis totalement inutile. Je suppose que tu penses ainsi accélérer la résolution des noms en adresse IP. Je ne suis pas sûr que tu y gagnes quelque chose… Les requêtes DNS sont mises en cache en ne prennent pas plus de quelques millisecondes (par exemple chez moi 15 ms pour résoudre ubuntu-fr.org lors de la première reqûte, 1ms ensuite)
Si c'est pour contourner les DNS menteurs, ou les blocages par DNS, il vaut mieux utiliser des résolveurs fiables et non intrusifs : ceux de FDN ou le 9.9.9.9

La modifications du fichiers hosts ne devrait intervenir que dans les cas suivants :
- développement en local de sites web ;
- avoir une résolution des noms des machines sur un (tout) petit réseau local ;
- faire du blocage de sites (publicitaires, malveillants, etc.)

Foromus · Le 24/02/2018, à 14:39

Merci bruno,

bruno a écrit :

Si c'est pour contourner les DNS menteurs, ou les blocages par DNS, il vaut mieux utiliser des résolveurs fiables et non intrusifs : ceux de FDN ou le 9.9.9.9

Ya un peu de ça...
Après, utiliser des résolveurs et autre non intrusifs, ce n'est plus dans mes cordes, donc, je m'abstiens... Mais si je trouve de bonnes explications là-dessus un jour, je verrai à tenter l'expérience.
Mais brisons-là, ce n'est effectivement pas le sujet...

nam1962 · Le 24/02/2018, à 15:31

Foromus a écrit :

(...) merci pour la volée de bois vert, il est vrai que "j'en ai ramassé" pas mal depuis que je suis passé sous Linux (au passage, migrer sous Linux, "faut en vouloir"...)(...)

Sourire.. tu n'as pas ramassé de volée de bois vert : on s'en est plutôt envoyé entre aidants.

Regarde les fils : les supra débutants sont total aidés, les moins tout à fait débutants se font parfois charrier (ça m'arrive quand je m'aventure).

Maintenant, je plussoie krodelabestiole : modifier le host quelque soit l'OS n'est pas du "total débutant" et quel est l'objectif qui ne pourrait être réalisé en GUI ?

krodelabestiole · Le 24/02/2018, à 17:16

bruno a écrit :

L'usage que tu fais de ton fichier hosts est à mon avis totalement inutile.

+1
par contre je ne pense pas qu'on s'éloigne du sujet d'origine. il arrive souvent que les question ici soient liées à une mauvaise pratique. je pense que c'est bien de mettre le doigt dessus plutôt que de répondre simplement à la question posée.

Dernière modification par krodelabestiole (Le 24/02/2018, à 17:41)

krodelabestiole · Le 24/02/2018, à 17:53

bruno a écrit :

il vaut mieux utiliser des résolveurs fiables et non intrusifs : ceux de FDN ou le 9.9.9.9

et ça fait plaisir de voir quelqu'un qui ne conseille pas bêtement openDNS (parce qu'il y a "open" dedans)
pour en savoir plus : https://www.nextinpact.com/news/105638- … privee.htm
et la mise en place n'est vraiment pas très compliquée.

Roschan · Le 24/02/2018, à 17:58

Heureusement que Dolphin n'autorise pas les manipulations de fichiers en tant que "root", j'ose espérer que c'est la me chose pour les autres gestionnaires de fichiers !

Bah...
- Nautilus (récent) l'autorise, il suffit de préfixer le chemin par admin://
- Nautilus (ancien) l'autorise, il suffit de passer par un plugin utilisant, je suppose, pkexec, et qui *en gros* revient à lancer "gksudo nautilus [path courant]" quand on fait clic-droit/ouvrir comme admin
- Nemo et Caja se comportent comme l'ancien nautilus
- PCmanFile et Thunar ont des mécanismes semblables

Dolphin lui bloque toute manipulation, et est le seul dans ce cas là.

admin:// n'est pas un protocole

Alors que file:// c'est un protocole ?

Si j'ai bien suivi, avec admin:// il s'agit d'accéder le fichier via le démon polkit en communicant avec celui-ci pour qu'il accorde les permissions à la lecture puis à l'enregistrement, plutôt que d'y accéder directement via son chemin, à ce titre on peut considérer que c'est bien un protocole, non ?

erresse a écrit :

La raison, c'est que cette opération modifie (parfois, ce n'est pas systématique) les droits et propriétés du fichier .Xauthority

En revanche, ce qui est systématique, c'est de corrompre les permissions des fichiers écrits par le logiciel lui-même (cf. le problème du prof qui voulait lancer ActiveInspire et qui avait tenté d'utiliser sudo comme une baguette magique, l'empêchant durablement d'utiliser normalement son logiciel)

"sudo" est nécessaire et, par conséquent, "gksudo" ou "kdesu" également pour lancer des applications graphiques avec les droits "root" (n'en déplaise aux puristes qui ne conçoivent pas qu'on effectue des tâches d'administration en mode graphique).

Les applications qui sont là pour faire des tâches d'administration sont priées de demander le mdp elles-mêmes. Ça n'a aucun sens de devoir chercher une interface bash pour y lancer gksudo xxxx : si xxxx doit être lancé comme admin, alors pourquoi le développeur n'intègre pas la demande du mot de passe au lancement de son machin ?

Même des vieux logiciels pas forcément exemplaires sur la gestion moderne des droits, comme Synaptic et GParted, font systématiquement l'effort de demander le mdp sans exiger de la part de l'utilisateur qu'il ouvre son terminal pour entrer "gksudo" avant.

Dernière modification par Roschan (Le 24/02/2018, à 18:15)

erresse · Le 24/02/2018, à 18:37

Roshan a écrit :

Même des vieux logiciels pas forcément exemplaires sur la gestion moderne des droits, comme Synaptic et GParted, font systématiquement l'effort de demander le mdp sans exiger de la part de l'utilisateur qu'il ouvre son terminal pour entrer "gksudo" avant.

À mon avis, ces deux applications ne doivent être utilisées QUE par l'administrateur, et donc elles demandent automatiquement une validation, mais le gestionnaire de fichiers ou l'éditeur de texte sont couramment utilisés par l'utilisateur "ordinaire" sans droits particuliers, sauf lorsqu'on veut intervenir sur des objets appartenant au système.
Ce serait plutôt contraignant de devoir entrer systématiquement un mot de passe pour éditer un fichier ou naviguer dans son arborescence, tu ne crois pas ? D'où sans doute le fait que ces applications ne demandent pas de validation... ou alors, on en revient au fonctionnement façon "dolphin" où une validation est demandée selon le type de l'objet traité.
Mais je reprécise que c'est juste "à mon avis", je ne suis pas dans le secret des dieux qui développent es applications.

Roschan · Le 24/02/2018, à 18:47

Nautilus est bien supposé demander le mot de passe à certains moments quand on veut accéder à des trucs appartenant à root, mais je dois admettre que je ne l'ai vu guère qu'en vidéo sur des versions de développement, jamais en vrai sur les versions stables.

Sinon -> https://forum.ubuntu-fr.org/viewtopic.php?pid=21877610

erresse · Le 24/02/2018, à 19:16

Dans mon système (Ubuntu-Mate 16.04) qui n'est donc pas le plus récent ni n'utilise Gnome-shell ni Weyland, j'ai juste installé le plugin "caja-gksu" qui me propose dans le menu contextuel de clic droit, le choix "Ouvrir en tant qu'administrateur".
Si l'objet sélectionné est un répertoire, il lance une nouvelle fenêtre de Caja avec les droits d'administration sur le répertoire indiqué.
Si l'objet sélectionné est un fichier texte, il ouvre ce fichier dans Pluma avec les droits d'administration pour le modifier.
Si l'objet sélectionné est d'une autre nature, il ouvre cet objet avec l'application prévue par défaut pour cet objet avec les droits d'administration, mais alors cela n'a guère d'intérêt (ouvrir un film en mode "sudo", bof...).
Évidemment, dans ces cas-là, il me demande une validation par le mot de passe de l'administrateur, ça va de soi !
Je n'ai donc pas forcément besoin d'ouvrir un terminal pour y lancer Caja ou Pluma avec "gksudo", tout se passe en mode graphique.
C'est peut-être (sûrement même) dangereux, bien sûr, mais j'ai la prétention de savoir ce que je fais et du coup... qu'est-ce que c'est pratique !!!

Roschan · Le 24/02/2018, à 19:23

Quitte à passer par des plugins externes :

Quelle différence entre caja-gksu et ajouter

for source in $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
do
	gedit admin://$(echo $source)
done

dans un fichier du dossier "scripts" de caja/nautilus/nemo/etc ? L'un n'est pas moins pratique que l'autre.

Je viens de commencer un plugin gedit qui ajoute "enregistrer en tant qu'admin" au menu, on verra si j'y arrive malgré la documentation fastueuse de gedit (sarcasme), mais ça n'a pas l'air impossible

nam1962 · Le 24/02/2018, à 19:51

Soluce élégante

N'est ce pas ce genre de script qui différencie les versions de certains soft ? (je pense par exemple à Back In Time qui une fois installé se propose en "Back In Time" et "Back In Time (root)" ?

Dans ce cas, ne serait ce pas à proposer au devs de Gedit où aux empaqueteurs ?

[Edit] il me semble que le sujet est le même avec Thunar, non ?

Dernière modification par nam1962 (Le 24/02/2018, à 19:52)

bruno · Le 24/02/2018, à 20:40

Roschan a écrit :

Heureusement que Dolphin n'autorise pas les manipulations de fichiers en tant que "root", j'ose espérer que c'est la me chose pour les autres gestionnaires de fichiers !
Bah...
- Nautilus (récent) l'autorise, il suffit de préfixer le chemin par admin://
- Nautilus (ancien) l'autorise, il suffit de passer par un plugin utilisant, je suppose, pkexec, et qui *en gros* revient à lancer "gksudo nautilus [path courant]" quand on fait clic-droit/ouvrir comme admin
- Nemo et Caja se comportent comme l'ancien nautilus
- PCmanFile et Thunar ont des mécanismes semblables
Dolphin lui bloque toute manipulation, et est le seul dans ce cas là.

Il n'y a rien de plus dangereux que d'ouvrir un gestionnaire de fichier graphique en tant que root. Je suis surpris que Dolphine soit le seul à l'interdire.

Roschan a écrit :

admin:// n'est pas un protocole
Alors que file:// c'est un protocole ?

J'aurai dû être plus précis ce n'est pas un schéma d'URI standard, file l'est. https://fr.wikipedia.org/wiki/Sch%C3%A9ma_d%27URI
À moins que tu n'aies une source qui montre que admin a été accepté en tant que schéma d'URI.

Roschan · Le 24/02/2018, à 21:01

je te trouvais pourtant particulièrement précis dans ta remarque

bruno a écrit :

admin:// n'est pas un protocole, et je trouve cela contre intuitif de l'utiliser comme protocole… (alors que l'usage de psudo protocoles comme network://, mtp://, etc. me semble tout à fait évident)

Non ce n'est pas intégré dans le standard, mais ce n'est pas le sujet : ça en suit la logique, la syntaxe, et ça n'a donc rien de farfelu, d'« abscon » ni d'« imbitable »

nam1962 · Le 24/02/2018, à 21:34

Farfelu sans doute pas, abscon et imbitable sûrement !
Le #48 est il inspirant ou idiot ?

Roschan · Le 24/02/2018, à 21:45

je dirais "idiot", on peut en faire un lanceur par confort, pour dépanner (cf la discussion ouverte dans "trucs et astuces"), mais un item dans le menu de gedit pour faire "enregistrer comme root" me semble être moins un bricolage

nam1962 · Le 25/02/2018, à 01:44

Tu n'as pas compris.
Mon exemple de backintime est qu'il propose d'office deux lanceurs dont un en root (il n'y a rien dans les menus)

Roschan · Le 25/02/2018, à 02:01

Si j'avais compris, et je réitère.

Si tu préfères te trimballer 2 lanceurs et devoir anticiper systématiquement avant d'ouvrir les fichiers, grand bien t'en fasse, moi pour l'instant j'ai ça https://github.com/Maestroschan/gedit-p … en-as-root et c'est indéniablement plus confortable même si c'est un affreux brouillon perfectible

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 23/02/2018, à 20:22

Re : [Résolu] sudo gedit réagit mal...

#27 Le 23/02/2018, à 21:16

Re : [Résolu] sudo gedit réagit mal...

#28 Le 23/02/2018, à 21:17

Re : [Résolu] sudo gedit réagit mal...

#29 Le 23/02/2018, à 21:20

Re : [Résolu] sudo gedit réagit mal...

#30 Le 24/02/2018, à 10:19

Re : [Résolu] sudo gedit réagit mal...

#31 Le 24/02/2018, à 11:39

Re : [Résolu] sudo gedit réagit mal...

#32 Le 24/02/2018, à 13:14

Re : [Résolu] sudo gedit réagit mal...

#33 Le 24/02/2018, à 14:12

Re : [Résolu] sudo gedit réagit mal...

#34 Le 24/02/2018, à 14:27

Re : [Résolu] sudo gedit réagit mal...

#35 Le 24/02/2018, à 14:39

Re : [Résolu] sudo gedit réagit mal...

#36 Le 24/02/2018, à 15:31

Re : [Résolu] sudo gedit réagit mal...

#37 Le 24/02/2018, à 17:16

Re : [Résolu] sudo gedit réagit mal...

#38 Le 24/02/2018, à 17:53

Re : [Résolu] sudo gedit réagit mal...

#39 Le 24/02/2018, à 17:58

Re : [Résolu] sudo gedit réagit mal...

#40 Le 24/02/2018, à 18:37

Re : [Résolu] sudo gedit réagit mal...

#41 Le 24/02/2018, à 18:47

Re : [Résolu] sudo gedit réagit mal...

#42 Le 24/02/2018, à 19:16

Re : [Résolu] sudo gedit réagit mal...

#43 Le 24/02/2018, à 19:23

Re : [Résolu] sudo gedit réagit mal...

#44 Le 24/02/2018, à 19:51

Re : [Résolu] sudo gedit réagit mal...

#45 Le 24/02/2018, à 20:40

Re : [Résolu] sudo gedit réagit mal...

#46 Le 24/02/2018, à 21:01

Re : [Résolu] sudo gedit réagit mal...

#47 Le 24/02/2018, à 21:34

Re : [Résolu] sudo gedit réagit mal...

#48 Le 24/02/2018, à 21:45

Re : [Résolu] sudo gedit réagit mal...

#49 Le 25/02/2018, à 01:44

Re : [Résolu] sudo gedit réagit mal...

#50 Le 25/02/2018, à 02:01

Re : [Résolu] sudo gedit réagit mal...

Pied de page des forums