vulgarisation de Root et sécurité (résolu)

provaire · Le 15/12/2018, à 08:31

Bonjour, si je me trompe de Forum veuillez m’en excuser.
Depuis les débuts de l’informatique démarrer avec un IBM 5100 grand public dans les années 1980, les créateurs et inventeurs (merci a eux) mettent tout en place pour que l’informatique ne soit pas seulement un outil réservé a quelques privilégiés.
Je constate (a mon grand regret) que la ligne de commande supplante encore en 2018 malgré des efforts sur le mode graphique (sur Ubuntu).

D’où vient cette négation systématique du mode graphique qui offre presque autant de possibilité que les lignes de commandes ?

Par ma petite expérience (18 ans sous Linux)je sais que les bêtises sont d’autant plus grave quant on fait une erreur en ligne de commandes un 5 au lieux d’un 7 ou un * a la place \ (je simplifie volontairement) surtout en Root.

Sachant qu’il est possible de naviguer sur le Web via une console (avec le navigateur adapté il me semble)
Si celle si est en Root elle présente autant de dangers si ce n’est plus qu’un mode graphique Root.

Ce que je voudrais comprendre s’est pourquoi un sudo nautilus est plus dangereux qu’un su en console ? la j'avoue ne pas comprendre la différence de dangerosité

ps:Je précise que je ne lance pas ce sujet pour faire polémique mais juste pour comprendre.

Dernière modification par provaire (Le 20/12/2018, à 18:17)

nam1962 · Le 15/12/2018, à 09:14

Je ne pige pas toute tes questions.

Pour la ligne de commande, elle n'est pas particulièrement privilégiée et je peux te dire que nombre de mes installés ne l'ont jamais utilisée (pas plus que des amis qui sont sous macOs et qui n'utilisent jamais leur terminal qui ressemble fort au notre).

Cela dit, le terminal a un intérêt quand on s'attaque à des tâches "industrielles" : mettre toutes les images d'un répertoire à la même taille, renommer les fichiers dans 3 répertoires différents....

...et est tout à fait intéressant, voire indispensable dans les fils d'aide, car il est agnostique en terme d'environnement et que son retour ne pèse rien.
Exemple : les sources, c'est 10 lignes ou... 4 grosses photos
En plus on a pas besoin de dire "clique sur le bouton bleu en bas à droite" à quelqu'un qui répond, "euhh, je vois un bouton vert en haut à gauche".
Donc quand tu n'as pas le loisir de faire une session à distance, le terminal est l'outil le plus simple et fiable.

Pour ta seconde question :

su

est à total éviter : tu deviens admin et tu crées un risque maximum de passer des commandes qu'il ne faudrait pas passer

sudo nautilus

est à total éviter : même si sudo est plus sain que su, car contingenté à une commande, il ne faut pas appeler le graphique comme ça, au risque de changer les droits des fichiers ouverts.
Si tu dois vraiment l'utiliser (ce qui est très improbable*), passe par :

sudo -H nautilus

*Ceci est un second cas ou la ligne de commande est à prioritiser car plus saine : nautilus n'a pas à être utilisé en mode admin, si tu dois copier un fichier détenu par root, par exemple, passe par

sudo cp /le/chemin/du/fichier

...dans ce dernier cas, pour revenir à ta première question, on est plus dans l'anodin, ni dans l'utilisation de Mme Michu et là l'outil sain est bien le terminal.

Dernière modification par nam1962 (Le 15/12/2018, à 09:39)

bruno · Le 15/12/2018, à 09:25

Bonjour,

Cela a déjà été expliqué à maintes reprises dans divers fils de discussions.
Il ne faut jamais lancer une application graphique en tant que root (nautilus ou autre, à quelques exceptions près).

Il faut bien comprendre que lorsque toto utilise la commande :

sudo application

l'application est lancé en tant que 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 /home/toto appartenant à root. La prochaine fois qu'il lancera l'application il risque 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.
Le forum regorge de ce type de problème avec la solution classique consistant à réattribuer la propriété des fichiers du dossier personnel avec chown.

D'autre part il me semble qu'il y a bien plus de risques de manipulations involontaires catastrophiques avec un gestionnaire de fichier graphique exécuté par root qu'en ligne de commandes. Un clic de souris ou un glissement malheureux arrive plus facilement qu'une commande de déplacement ou de suppression.

Si la ligne de commande est très utilisée pour dépanner les gens sur le forum c'est avant tout pour des raisons pratiques :
- on ignore souvent l'environnement de bureau utilisé par le demandeur ;
- donner une commande est bien plus rapide que d'indiquer d'aller cherche dans le énième sous menu du énième onglet de la boîte de dialogue d’une application.
De manière générale, la ligne de commande est le moyen le plus rapide, le plus ergonomique et le plus efficace pour administrer un système (c'est aussi vrai sous Windows ou MacOS).
L'utilisateur d'une machine de bureau n'en a généralement pas besoin car il dispose de tous les outils en mode graphique pour gérer ses périphériques, logiciels, etc.

---------------------

EDIT

Pour rebondir sur ce que dit nam1962, sudo -H est un moindre mal ($HOME=/root) mais idéalement il faudrait employer sudo -i (toutes les variables d’environnement sont celles de root).

Dernière modification par bruno (Le 15/12/2018, à 09:47)

maxire · Le 15/12/2018, à 09:37

Salut,

L'utilisation de sudo nautilus n'est pas spécifiquement dangereuse.
Le problème est qu'elle risque de changer le propriétaire de ~.config/dconf/user et également d'autres répertoires/fichiers utilisateurs en root ce qui empêche par la suite de démarrer correctement une session graphique utilisateur faute de pouvoir accéder à l*a base dconf utilisateur ou d'autres répertoires/fichiers.
L'utilisation de l'option -H pallie ce problème.

Ensuite il est vrai que si tu fais n'importe quoi en mode super utilisateur tu es certain d'obtenir n'importe quoi.

Edit : Bruno vient de parfaitement explquer le problème de sudo en mode graphique.

Dernière modification par maxire (Le 15/12/2018, à 09:39)

rogn... · Le 15/12/2018, à 09:47

Salut,

Bien qu'avec 10 ans de Linux derrière moi, je m'y reprends à deux fois avant de faire quelque chose en root. Donc, je dirais que tant que l'on peut éviter root et sudo, on l'évite, que ce soit en graphique ou en cli. Flatpak permet entre autres d'éviter des opérations root. Mais aussi ce tuto qui explique comment installer youtube-dl, je l'ai repris de sorte que root n'intervienne pas.

nam1962 · Le 15/12/2018, à 09:48

bruno a écrit :

(...)
EDIT
Pour rebondir sur ce que dit nam1962, sudo -H est un moindre mal ($HOME=/root) mais idéalement il faudrait employer sudo -i (toutes les variables d’environnement sont celles de root).

ou

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit

ou

gedit admin:///path/to/document

Pour le fun, voilà ce qui t'arrive quand tu poses la question sur askubuntu : https://askubuntu.com/questions/1009574 … it-as-root

Dernière modification par nam1962 (Le 15/12/2018, à 09:49)

bruno · Le 15/12/2018, à 09:51

@nam1962 : ça ce sont des spécificités de l'environnement GNOME. D'autres environnements de bureau on fait des choix bien plus élégants, simples et ergonomiques (KDE pour ne pas le citer ).

provaire · Le 15/12/2018, à 11:00

nam1962 a écrit :

Je ne pige pas toute tes questions.

Elle est portant très simple, je vais donc la reformuler:
Des deux façons d’accéder au Root : (quant s'est nécessaire)
une Graphique l'autre en console. Voyant a plusieurs reprises un rappel sur pas de Root en mode graphique.
Je me permet de demander pourquoi le mode graphique serait il plus dangereux que le mode Root console.

Je connais le risque du super admin ,mais je ne vois pas de différences entre les deux façons d'accéder au mode.

Pour répondre a l'ensemble: Le mode (Root) graphique peut modifier l'utilisateur (hors accident de souris) chose impossible en console puisque la commande est plus ciblée. Vrai ou faux?
Qu'en est il si je fais la commande en console avant la fin j'arrête l'ordi accidentellement (un peut comme accident de souris) la session n'aura telle pas changer d'User?

Dernière modification par provaire (Le 15/12/2018, à 11:13)

maxire · Le 15/12/2018, à 11:45

provaire a écrit :

pas de Root en mode graphique.

Plus exactement, ne pas utiliser sudo sans l'option -H ( je ne vois pas trop comment l'option -i peut fonctionner car c'est l'équivalent de su ) pour passer en mode super utilisateur en mode graphique !

Anciennement il fallait utiliser gksudo ou pkexec et depuis la 17.10 utiliser le chemin admin:///chemin vers le fichier ou répertoire avec gedit/pluma/leafpad/mousepad ou nautilus/caja/nemo/thunar/PCmanfm (avec KDE je ne sais pas) pour passer en mode root.

Les dernières versions du serveur Xorg n'acceptent plus de connexions de clients tournant sous un autre utilisateur que celui ayant lancé le serveur, à moins d'utiliser Xhost et encore !
Avec Wayland c'est maintenant impossible à moins d'utiliser admin:///... .

Edit :

Je me suis avancé un peu vite, Xorg n'est pas si bien verrouillé que cela, entre Archlinux et Ubuntu je me mélange un peu !

Dernière modification par maxire (Le 15/12/2018, à 12:12)

provaire · Le 15/12/2018, à 12:04

Maxire a écrit :

Plus exactement, ne pas utiliser sudo sans l'option -H

Merci pour cette précision.
J'utilisais par habitude le gksudo / chemin aujourd'hui sudo/chemin.
J'ai par petits bidouillages planté de la même façon une session en console comme en graphique (Xorg modif) s'est pour cela que je voulais comprendre qu'es qui permettait de dire qu' une méthode est plus dangereuse que l'autre. Je dois être obtus car malgré les réponses je reste sur ma faim.

maxire · Le 15/12/2018, à 12:22

L'accès à Xorg en mode super utilisateur est toujours dangereux et si cet accès est établi avec sudo sans option il existe en prime un risque de blocage de l'environnement graphique de l'utilisateur, c'est tout.

Avec admin:///, le serveur graphique Xorg n'a plus pour client le super utilisateur, donc utilise admin:///...

bruno · Le 15/12/2018, à 13:10

maxire a écrit :

Plus exactement, ne pas utiliser sudo sans l'option -H ( je ne vois pas trop comment l'option -i peut fonctionner car c'est l'équivalent de su ) …

Cf. man sudo, man su

sudo -i est l'équivalent de su -l (ou su -). Cela permet d'obtenir un vrai shell root avec l’environnement utilisateur de root (pas seulement $HOME).

su ne devrait pas être utilisé sous Ubuntu.

---
Non seulement il est dangereux d'ouvrir les applications graphiques en root mais en plus c'est inutile. Je crois que la volonté d'ouvrir un gestionnaire de fichiers en root procède plus des mauvaises habitudes prises sous Windows. D'ailleurs, curieusement les utilisateurs de MacOS ne se posent pas ctete question.

Dernière modification par bruno (Le 15/12/2018, à 13:11)

maxire · Le 15/12/2018, à 13:22

@bruno, j'ai un problème avec sudo -i sous mate, je peux lancer l'éditeur pluma mais pas le gestionnaire de fichiers caja (erreur de segmentation), d'où ma réflexion.

nam1962 · Le 15/12/2018, à 13:38

@provaire, je pige un peu mieux.
L'accès root correspond à une tache d'administration système.
L'utilisateur basique n'a en principe aucun besoin du genre.

Celui qui veut administrer en profondeur son système doit le faire en connaissance de cause et avec les méthodes et procédures appropriées.
La bidouille graphique en root ne fait tout simplement pas partie de ces méthodes et procédures.
Ce n'est pas spécifique aux distros GNU/Linux : c'est exactement la même chose pour les OS privateurs, modulo le fait que sous W$, tout un tas de soi disant outils graphiques, tous plus ou moins douteux ou fragiles, traînent un peu partout (les magnifique failles de cCleaner en sont un bel exemple.)

Si c'est çà que tu appelle de la "vulgarisation de root", ce n'est absolument pas le cas, c'est juste de la prise de risque à l'aveugle.

Si tu as de l'admin système à faire sur ta *buntu, dis ici tes besoins, il y aura toujours de bonnes âmes pour t'aider à le faire sans risque.... en lignes de commande

Dernière modification par nam1962 (Le 15/12/2018, à 14:46)

bruno · Le 15/12/2018, à 14:41

@maxire : peut-être un bug de caja ?

Quoiqu'il en soit un gestionnaire de fichier devrait refuser de se lancer en tant que root (c'est le cas de dolphin).
Je n'ai pas pensé à évoquer le fait que la plupart des gestionnaires de fichiers permettent de faire aussi du smb, (s)ftp, nfs, etc. ce qui expose potentiellement à de graves ennuis lorsqu'on est root…

Dernière modification par bruno (Le 15/12/2018, à 14:42)

provaire · Le 15/12/2018, à 14:58

nam1962 a écrit :

@provaire, je pige un peu mieux.
Si c'est çà que tu appelle de la "vulgarisation de root", ce n'est absolument pas le cas, c'est juste de la prise de risque à l'aveugle.

Merci de comprendre car il est compliqué d'expliquer ou de demander sans un échange.
Comme dis précédemment cela fait 18 ans que je travaille sous Linux avec en principale distribution Ubuntu. Les lignes de commandes me file des boutons (comme sous d'autres OS) je suppose ne pas être le seul (mais j'ai tendance a mettre les pieds dans le plat).
J'ai donc sans autre log de pacotille décidé de faire de l'admin en graphique (plus long certes ) je sais pour l'avoir tester que si la console est fermée on quitte le Root graphique et que le seul véritable danger est dans une fausse manip (comme en console d’ailleurs).
Se que j'appelle la vulgarisation de l'informatique et principalement de Ubuntu s'est justement cette possibilité en graphique d'aller a l'essentiel sans passer des heures a comprendre pourquoi telle ligne de commande fonctionne et que l'autre sous prétexte d'un espace plante (tout parfois).
Exemple : installation d'un logiciel ou certains fichiers vont dans un dossier réservé a l'admin
En graphique je modifie les permission sur le fichier et je peux utiliser mon log sans autre manip.

On est de toute façon d'accord sur le fond toutes manip en admin est dangereuses.

Par contre quelle sécurité offre la ligne de commande que n'offre pas le mode graphique?

nam1962 · Le 15/12/2018, à 15:14

1 - la commande légitime n'interfère pas avec les permissions
2 - la commande est traçable :

history

3 - comme déjà dit, la commande est agnostique en terme d'environnement et de finalisation : tu peux en parler à quelqu'un qui ne connaît, ni ne voit ton GUI
4 - la commande permet les traitements par lots
5 - la commande est ultra réplicable
6 - les commandes sont très abondamment documentées
7 - je suis sûr que les petits camarades ont plusieurs points complémentaires, voire plus essentiels encore

Comme tu le dis toi-même, l'admin n'est pas anodin, le faire en "shadow IT" ne va rien apporter que du risque non maîtrisé.

De la même manière, les feuilles de calcul c'est du GUI parfaitement dangereux, ce n'est pas pour rien que la banque JP Morgan a impose depuis cettte année à ses analystes l'apprentissage de python : le code ne tue personne, est documenté et documentable, la sécurité commence par là !
En plus il est plus rapide et reproductible à l'infini (une tâche déjà faite se refait par simple copier/coller ou presque)

Dernière modification par nam1962 (Le 15/12/2018, à 15:39)

moko138 · Le 15/12/2018, à 15:25

provaire a écrit :

malgré les réponses je reste sur ma faim.

Si j'ai bien compris tes questions, tu veux dire :
« sachant qu'on peut se tromper tout autant
en ligne de commande (par exemple, à cause d'une faute de frappe derrière "sudo mv ...")
qu'en mode graphique (sudo + nautilus/caja/thunar/pcmanfm +déplacer ou jeter un élément),
pourquoi cet anathème jeté sur le second cas ? »

Si j'ai mal compris, corrige-moi.
Et si telle est bien ta question, la réponse est que,
même si on ne fait pas d'erreur dans le "déplacer ou jeter un élément",
le simple fait d'avoir lancé le gestionnaire de fichiers avec sudo est une erreur qui va bloquer une partie de ta session ensuite. (Même après redémarrage).

Donc en effet, la ligne de commande ne prémunit aucunement contre les fautes de frappe ou de conception.
Mais elle protège contre les blocages consécutifs à sudo <commande-graphique>

Dernière modification par moko138 (Le 15/12/2018, à 15:25)

nam1962 · Le 15/12/2018, à 15:31

+1 (et moko138 m'a assez tancé à mes débuts sur ce sujet précis )
On peut ajouter qu'un clic malencontreux arrive plus vite qu'une faute dans une commande.
.. et qu'on peut oublier qu'on est en GUI "admin"
(mais il y a bien sûr des tas de fautes possibles dans les commandes dont des fatales...)

Dernière modification par nam1962 (Le 15/12/2018, à 15:32)

provaire · Le 15/12/2018, à 16:48

moko138 a écrit :

Si j'ai bien compris tes questions, tu veux dire :
« sachant qu'on peut se tromper tout autant
en ligne de commande (par exemple, à cause d'une faute de frappe derrière "sudo mv ...")
qu'en mode graphique (sudo + nautilus/caja/thunar/pcmanfm +déplacer ou jeter un élément),
pourquoi cet anathème jeté sur le second cas ? »

-Bonjour, je ne jette pas d’anathème sur quoi que ce soit j’essaye juste de raisonner avec neutralité ( manip difficile dans le monde Linux ?) Je connais les risques de super admin et parfois je m’en amuse (pas sur mon DD de travail)

moko138 a écrit :

Si j'ai mal compris, corrige-moi.
Et si telle est bien ta question, la réponse est que,
même si on ne fait pas d'erreur dans le "déplacer ou jeter un élément",
le simple fait d'avoir lancé le gestionnaire de fichiers avec sudo est une erreur qui va bloquer une partie de ta session ensuite. (Même après redémarrage).

-Pour l’instant je n’ai jamais bloquer une session en faisant la manip en Root graphique et je n’ai pas remarqué de modif autre que celle que je souhaitai. Comparaison de l’image système avant – aprés.
Donc si je me trompe (et ça m’arrive) il faudrait que le mode Root graphique modifie un accès sans mon consentement sur un fichier système ?
Pouvez vous être m’expliquer svp ?

Évidemment on parle d’un Root sans SSH

nam1962 · Le 15/12/2018, à 16:56

provaire a écrit :

(...)
Donc si je me trompe (et ça m’arrive) il faudrait que le mode Root graphique modifie un accès sans mon consentement sur un fichier système ?
Pouvez vous être m’expliquer svp ?

---> https://askubuntu.com/questions/270006/ … plications

provaire · Le 15/12/2018, à 17:56

nam1962 a écrit :

---> https://askubuntu.com/questions/270006/ … plications

Mon anglais étant douteux et très vieux je me rabat sur traduc et mon british.

Donc si j'ai bien compris la modification d'un fichier en Root en change le propriétaire? Il me semblais que c'était la création d'un fichier ?
N'ayant jamais rencontré ce problème ( malgré mon plaisir de bidouillage), j'avoue que m'a méfiance était certainement limite sur la question.

Je vous remercie a tous pour vos explications et les liens fournis .

Tien un nautilus-admin sa peut s'essayer.

nam1962 · Le 15/12/2018, à 18:00

Cela dit, tu peux aussi nous dire une manip que tu fais régulièrement avec ta méthode, histoire qu'on voie la commande qui la remplacerait sans risque et qui serait disponible pour toute réplication.

erresse · Le 15/12/2018, à 19:05

provaire a écrit :

Tien un nautilus-admin sa peut s'essayer.

Malheureusement, aux dernières nouvelles, il paraîtrait que cette extension pour Nautilus ait disparue des dépôts 18.04 !
Personnellement, je m'en sers abondamment pour naviguer et éditer en super-utilisateur (autant que de besoin, s'entend) et ça me donne entière satisfaction !
Mais moi, je suis sous Ubuntu-Mate, je n'ai pas Nautilus ni Gedit, mais Caja et Pluma qui supportent encore très bien l'extension.
(pourvu que ça dure... j'ai horreur du modernisme !)

provaire · Le 15/12/2018, à 21:13

erresse a écrit :

Malheureusement, aux dernières nouvelles, il paraîtrait que cette extension pour Nautilus ait disparue des dépôts 18.04 ! roll
Personnellement, je m'en sers abondamment pour naviguer et éditer en super-utilisateur (autant que de besoin, s'entend) et ça me donne entière satisfaction !
Mais moi, je suis sous Ubuntu-Mate, je n'ai pas Nautilus ni Gedit, mais Caja et Pluma qui supportent encore très bien l'extension. tongue
(pourvu que ça dure... j'ai horreur du modernisme !)

Je confirme que les dernières nouvelles sont un hoax. J'ai la 18.04 et gnome et ça fonctionne

sudo apt install nautilus-admin

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/12/2018, à 08:31

vulgarisation de Root et sécurité (résolu)

#2 Le 15/12/2018, à 09:14

Re : vulgarisation de Root et sécurité (résolu)

#3 Le 15/12/2018, à 09:25

Re : vulgarisation de Root et sécurité (résolu)

#4 Le 15/12/2018, à 09:37

Re : vulgarisation de Root et sécurité (résolu)

#5 Le 15/12/2018, à 09:47

Re : vulgarisation de Root et sécurité (résolu)

#6 Le 15/12/2018, à 09:48

Re : vulgarisation de Root et sécurité (résolu)

#7 Le 15/12/2018, à 09:51

Re : vulgarisation de Root et sécurité (résolu)

#8 Le 15/12/2018, à 11:00

Re : vulgarisation de Root et sécurité (résolu)

#9 Le 15/12/2018, à 11:45

Re : vulgarisation de Root et sécurité (résolu)

#10 Le 15/12/2018, à 12:04

Re : vulgarisation de Root et sécurité (résolu)

#11 Le 15/12/2018, à 12:22

Re : vulgarisation de Root et sécurité (résolu)

#12 Le 15/12/2018, à 13:10

Re : vulgarisation de Root et sécurité (résolu)

#13 Le 15/12/2018, à 13:22

Re : vulgarisation de Root et sécurité (résolu)

#14 Le 15/12/2018, à 13:38

Re : vulgarisation de Root et sécurité (résolu)

#15 Le 15/12/2018, à 14:41

Re : vulgarisation de Root et sécurité (résolu)

#16 Le 15/12/2018, à 14:58

Re : vulgarisation de Root et sécurité (résolu)

#17 Le 15/12/2018, à 15:14

Re : vulgarisation de Root et sécurité (résolu)

#18 Le 15/12/2018, à 15:25

Re : vulgarisation de Root et sécurité (résolu)

#19 Le 15/12/2018, à 15:31

Re : vulgarisation de Root et sécurité (résolu)

#20 Le 15/12/2018, à 16:48

Re : vulgarisation de Root et sécurité (résolu)

#21 Le 15/12/2018, à 16:56

Re : vulgarisation de Root et sécurité (résolu)

#22 Le 15/12/2018, à 17:56

Re : vulgarisation de Root et sécurité (résolu)

#23 Le 15/12/2018, à 18:00

Re : vulgarisation de Root et sécurité (résolu)

#24 Le 15/12/2018, à 19:05

Re : vulgarisation de Root et sécurité (résolu)

#25 Le 15/12/2018, à 21:13

Re : vulgarisation de Root et sécurité (résolu)

Pied de page des forums