Pourquoi dois-je utiliser Sudo pour presque tout?
Si je comprends bien la philosophie Linux, Sudo doit être utilisé avec parcimonie et la plupart des opérations doivent être effectuées en tant qu'utilisateur sous-privilégié. Mais cela ne semble pas avoir de sens, car je dois toujours saisir Sudo, que je gère des packages, que j'édite des fichiers de configuration, que j'installe un programme à partir de la source ou que vous ayez. Ce ne sont même pas des choses techniques, tout ce qu'un utilisateur régulier fait.
Cela me rappelle beaucoup l'UAC de Windows, que les gens désactivent ou configurent pour ne pas exiger de mot de passe (juste un clic). En outre, les utilisateurs Windows de nombreuses personnes sont également des comptes d'administrateur.
En outre, j'ai vu certaines personnes afficher des commandes qui nécessitent des privilèges Sudo sans Sudo. Leur système est-il configuré de telle manière que Sudo n'est pas requis?
Vous avez mentionné ces fonctions d'administration système
gestion des packages, modification des fichiers de configuration, installation d'un programme à partir des sources
comme des choses qui
tout ce qu'un utilisateur régulier fait
Dans un système multi-utilisateur typique, il ne s'agit pas d'actions utilisateur ordinaires; un administrateur système s'en inquiéterait. Les utilisateurs ordinaires (non "sous privilégiés") peuvent alors utiliser le système sans se soucier de son entretien.
Sur un système domestique, oui, vous finissez par devoir administrer le système ainsi que l'utiliser.
Est-ce vraiment si difficile d'utiliser Sudo? N'oubliez pas que si c'est juste votre système, il n'y a aucune raison pour que vous ne puissiez pas non plus passer dans un root Shell (Sudo -s - voir cet article pour un aperçu des différents moyens d'obtenir un shell racine) et/ou configurer Sudo pour ne pas demander de mot de passe.
Sudo/Root est utilisé chaque fois que vous faites quelque chose qu'un utilisateur standard ne devrait pas avoir la capacité de faire pour risquer d'endommager/de modifier la configuration du système d'une manière que l'administrateur du système ne permettrait pas normalement.
que je gère des packages, que je modifie des fichiers de configuration, que j'installe un programme à partir des sources ou que sais-je encore.
Toutes ces fonctions sont techniquement d'administration et peuvent endommager considérablement votre système si quelque chose de incorrect est fait. Dans un environnement d'entreprise, en tant qu'administrateur système, ce sont des choses que je ne laisserais PAS mon utilisateur faire sans ma connaissance expresse, d'où Sudo.
Par exemple, si un fichier package/config pouvait être modifié sans privilèges élevés, il serait extrêmement simple pour une source extérieure d'exécuter simplement du code distant qui pourrait casser/compromettre votre système. En forçant ces actions à exiger un accès root, cela vous oblige en tant qu'utilisateur à décider si ces actions ont lieu ou non.
C'est très similaire à UAC avec windows, c'est en fait là où windows a eu l'idée de UAC.
Le devis que vous recevez la première fois que vous utilisez Sudo est très approprié et très important:
Nous espérons que vous avez reçu la conférence habituelle de l'administrateur système local. Cela se résume généralement à ces trois choses:
#1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility.
Surtout # 2, réfléchissez avant de taper. C'est une raison importante pour laquelle Sudo existe, lorsque vous tapez une commande et qu'elle démarre "doit être root pour effectuer cette action" cela vous oblige à vous arrêter et à PENSER à ce que vous faites réellement.
En outre, j'ai vu certaines personnes afficher des commandes qui nécessitent des privilèges
SudosansSudo. Leur système est-il configuré de telle manière queSudon'est pas requis?
Vous devez exécuter ces commandes en tant que superutilisateur, mais vous n'avez pas à les exécuter à l'aide de Sudo. Vous pouvez par exemple utiliser à la place su ou doas (remplacement d'OpenBSD pour Sudo), ou vous pouvez simplement vous connecter en tant que root.
Donc, s'ils affichent leurs commandes ici sans Sudo, ils supposent que le lecteur utilisera simplement sa façon préférée d'exécuter ces commandes en tant que superutilisateur.
Cela ne signifie certainement pas qu'ils peuvent exécuter ces commandes en tant qu'utilisateur normal.
Une fonction de sécurité offerte par Sudo est que vous pouvez avoir un système sans root mot de passe , de sorte que l'utilisateur de root ne peut pas se connecter directement. Cela offre une protection supplémentaire aux utilisateurs qui choisissent des mots de passe faibles - l'attaquant essayant de forcer le mot de passe par brute (via SSH ou autre) devra d'abord trouver un nom d'utilisateur valide.
Un autre aspect est une gestion des privilèges plus fine. Penser à make; Sudo make install vs faire make; make install en tant que root. Beaucoup de choses peuvent mal se passer pendant make. Un outil mal configuré peut essayer d'écraser un fichier système important, "nettoyer" le /lib au lieu du répertoire courant, consommez tous les disponibles RAM et bloquez le système, etc. make install est une petite action simple avec beaucoup moins de probabilité d'erreur fatale.
Le fait est que, historiquement, un système est vraiment destiné à être partagé par plusieurs utilisateurs qui se connectent, font des trucs et se déconnectent. D'où la distinction entre administrateur et utilisateur normal. De tels systèmes existent toujours dans les laboratoires universitaires et vous pouvez sentir la différence si vous utilisez de tels ordinateurs. Le PC domestique où vous êtes le seul utilisateur et qui doit également agir en tant qu'administrateur est vraiment un développement beaucoup plus tard.
Un ordinateur est un outil. Essayons une analogie avec un autre outil, disons une poêle à frire. Parfois, vous devez prendre soin de votre poêle. Par exemple, vous devez le nettoyer avec du savon à vaisselle. Diriez-vous que le savon à vaisselle est un ingrédient obligatoire de toute recette pour laquelle vous utilisez la poêle à frire? Vous ne verrez jamais de "savon à vaisselle" répertorié comme ingrédient dans les livres de cuisine. C'est nécessaire, mais la préparation de l'outil est une autre affaire, donc les livres de cuisine ne le mentionnent pas. La poêle doit être nettoyée, mais ce n'est pas sa raison d'être.
C'est un peu la même chose pour votre ordinateur. Il doit être configuré et pris en charge, mais ce n'est pas pour cela qu'il est fait. Vous en prenez soin, vous le configurez pour qu'il fonctionne correctement. Une fois cela fait, vous pouvez l'utiliser, non pas en tant qu'administrateur système, mais en tant qu'utilisateur. C'est pour ça qu'il est fait. Lorsque vous êtes un utilisateur, vous n'avez plus besoin de Sudo . Utilisez simplement l'outil que vous avez préparé à l'avance. Bien sûr, de temps en temps, vous devrez utiliser les privilèges root, tout comme vous devez nettoyer votre poêle à frire aussi souvent que vous l'utilisez pour cuisiner.
Donc, sans trop exagérer, nous pourrions dire que vous jamais avez besoin Sudo (ou le mot de passe root) pour utiliser votre ordinateur. Uniquement pour préparer votre ordinateur.
Je parie que c'est parce que vous utilisez un logiciel GUI pour tout sauf les tâches d'administration système, ou que vous parlez de serveurs Linux, auquel cas la plupart des accès seront naturellement l'administration système. Par conséquent, il peut sembler que faire quoi que ce soit dans le Shell nécessite Sudo.
Il est également possible d'utiliser le Shell pour vos tâches quotidiennes. Gérer vos fichiers personnels dans ~, éditer des fichiers, discuter sur IRC, compiler du code, naviguer sur le Web, tout cela est réalisable dans un Shell. J'utilise même bc comme calculatrice incontournable. Certaines choses sont plus faciles à faire via une interface graphique, d'autres sont plus faciles à faire via le shell - même si vous préférez utiliser l'interface graphique, le shell excelle souvent dans les opérations par lots et l'automatisation (pensez aux scripts shell). Personnellement, j'utilise celui qui convient le mieux à la tâche à accomplir.
Dans certains cas, c'est une bonne idée de configurer votre système de façon à ce que vous n'ayez pas besoin d'utiliser Sudo à chaque fois pour des opérations qui nécessitent par défaut root mais ne risquent pas de causer de problèmes. Un exemple est que je travaille avec du matériel qui implique l'utilisation de ports série, et j'ai mis en place des règles udev pour donner accès aux périphériques en tant qu'utilisateur normal sans avoir à être root.
Je ne pense pas que ce soit une bonne idée de configurer Sudo pour ne pas exiger de mot de passe. Il est trop facile de gâcher tout votre système avec une commande mal saisie ou un script malveillant.
Si vous devez effectuer des tâches qui nécessitent absolument root tout le temps, pourquoi ne pas laisser un Sudo -s root Shell s'exécutant dans une fenêtre de terminal? Ensuite, il sera disponible sans avoir à taper le mot de passe, et il n'est pas aussi facile à utiliser accidentellement. J'ai même configuré mon invite Shell pour qu'elle soit rouge vif dans un shell racine.
[...] Mais cela ne semble pas avoir de sens, car je dois toujours saisir Sudo, que je gère des packages, que j'édite des fichiers de configuration, que j'installe un programme depuis la source ou que vous ayez. [...]
L'adjectif implicite lié à tout cela est qu'il s'agit de à l'échelle du système ou global changements. Vous devez considérer les origines d'Unix comme un système multi-utilisateur1 où plusieurs utilisateurs utiliseraient la même installation à distance. Il ne serait pas logique pour un utilisateur profane de permettre de modifier les paramètres globaux pour tous les utilisateurs. C'était le privilège et la responsabilité de l'administrateur système, de la racine.
Dans un environnement multi-utilisateur, vous disposez respectivement du logiciel préinstallé et de sa configuration à l'échelle du système sous /usr Et /etc. Toucher ces emplacements nécessiterait des autorisations root. Mais comme le logiciel Unix est écrit en pensant aux utilisateurs multiples, vous pouvez compiler et installer le logiciel sous le répertoire $HOME2et disposez de vos propres fichiers de configuration sous votre domicile, où vous pouvez modifier les fichiers librement sans être un super utilisateur.
En plus d'installer votre propre logiciel sous la maison, la plupart des logiciels à l'échelle du système liront la configuration spécifique à l'utilisateur de $HOME Juste après avoir lu la configuration de /etc. Cela vous permet de personnaliser presque tout sans jamais aller root.
Avec un PC personnel, dans un seul paramètre utilisateur principal, vous pouvez utiliser Sudo et vous frayer un chemin vers ce que vous aimez. Mais c'est habituel à ne pas faire appuyez sur la configuration de l'application dans /etc Mais fournissez toujours une configuration spécifique à l'utilisateur à la maison. De cette façon, vous pouvez permettre à votre gestionnaire de packages de réinitialiser les configurations à l'échelle du système lors des mises à niveau. L'installation de nouveaux logiciels à l'échelle du système est assez OK dans le cadre d'un utilisateur unique; les packages distro n'assument pas les alternatives, c'est donc une solution facile.
Je laisserai mon gestionnaire de paquets installer des trucs dans le monde mais tous les trucs compilés à partir de sources et autodidactes que je laisse sous $HOME. Et je n'ai pas à Sudo pour tout ça.
Si vous avez des fichiers de données, du stockage en dehors de votre $HOME, N'hésitez pas à chown ou chgrp les répertoires à votre nom afin que vous puissiez accéder aux fichiers sans Sudo .
[1] (un peu ironique car Unix était censé être une version "mono-utilisateur" du système d'exploitation Multics)
[2] (si le système le permet en ne montant pas les partitions home comme noexec)
Dans les types de systèmes multi-utilisateurs pour lesquels UNIX (et, par descendance, Linux) a été conçu, il ne s'agit pas d'actions ordinaires utilisateur =. Un administrateur système peut les exécuter, mais pas les utilisateurs standard, et le système demande donc de s'assurer que l'administrateur système souhaite réellement le faire.
Mais même dans les systèmes domestiques à utilisateur unique, ce ne sont pas des actions utilisateur ordinaires . On peut généralement avoir à faire cela lors de la configuration initiale du système, mais une fois que c'est terminé, n utilisateur typique ne devrait pas avoir à le faire très souvent. La plupart des utilisateurs types travaillent simplement sur des fichiers dans leur répertoire personnel (ou leurs sous-répertoires), en utilisant des programmes/packages déjà installés, et vous n'avez pas besoin de Sudo pour cela. Ou ils peuvent fonctionner dans un répertoire spécial ailleurs sur le système qui a été réservé à cet effet, et vous avez besoin de Sudo pour le configurer, mais vous n'avez généralement besoin de le faire qu'une seule fois.
Pourquoi est-ce important? Parce que "mono-utilisateur" est un terme impropre: vous n'êtes pas le seul utilisateur de votre machine, même si vous pouvez être son seul humain utilisateur. Même sur une installation Linux domestique classique, de nombreux programmes sont configurés pour utiliser la machine de différentes manières, simulant souvent quelque chose qu'un humain pourrait faire s'il avait le temps et l'attention à épargner: sauvegardes, mises à jour, analyse de logiciels malveillants et comme. La plupart du temps, ces utilisations sont totalement bénignes, mais même pour certaines d'entre elles, il est toujours prudent de s'assurer que l'utilisateur souhaite vraiment le faire. Et lorsque ces cas se présentent, c'est à cela que sert Sudo. L'ordinateur vérifie juste pour s'assurer que c'est bien vous qui voulez faire ce que quelqu'un (peut-être vous, peut-être un programme) a dit que vous avez fait. Et ce n'est même pas entrer dans la possibilité de logiciels malveillants, que vous ne voulez certainement pas masquer comme vous.
Ce n'est probablement pas aussi courant que représenté, mais cela se produit généralement lorsque quelque chose de décontracté nécessite en interne un appel système privilégié beaucoup plus générique pour atteindre son résultat, par exemple:
- Démontez et emportez une clé USB.
umountest une commande sérieuse car vous pouvez démonter beaucoup de choses avec. - Connectez-vous au réseau sans fil local. Rien d'extraordinaire, mais la configuration réseau (
ifup, etc.) est réservée au superutilisateur. - Applications à mise à jour automatique qui refusent de s'exécuter si elles ne sont pas mises à jour. Update = install, et cela pourrait installer beaucoup de choses, y compris des choses que vous ne voulez pas.
Les systèmes évoluent généralement pour réduire le nombre de ces cas. Les clés USB sont désormais montables par l'utilisateur et les réseaux peuvent être connectés par l'utilisateur. Mais ce n'était pas toujours comme ça.
Pour défendre la personne qui a écrit la question initiale, j'ai eu la même question dans les années passées, mais j'ai adopté une approche différente.
La plupart des réponses ici pourraient simplement être jouées en boucle, car elles insistent toujours sur le même point à propos de Sudo et de root. Permettez-moi d'ajouter une perspective différente à ce sujet:
La façon dont j'ai appris Unix ET Linux à l'envers était en utilisant un de mes ordinateurs comme "cobaye". J'installerais SCO Linux, et finalement Solaris puis Linux beaucoup plus tard, tout en expérimentant joyeusement en tant que root pour pouvoir lire et/ou explorer la hiérarchie des répertoires et tous les fichiers avec un accès illimité, également créer des comptes "utilisateur normal" sur ma boîte multi-utilisateur maison, même si j'étais le seul utilisateur. Et je suis content de l'avoir fait de cette façon. J'ai tellement appris sur la "philosophie Unix" et la façon dont Unix était destiné à être utilisé par mon expérimentation.
J'ai eu beaucoup de plaisir à apprendre la sécurité et à exécuter des commandes dangereuses en tapant rm -rf/* dans un terminal en tant que root. (NE FAITES PAS CELA! IL FLEXIBLE VOTRE SYSTÈME !!) J'ai fait des choses comme ça et bien d'autres commandes, juste pour voir ce qui se passerait en temps réel. J'ai fait ce genre de choses en connaissant les conséquences à l'avance, mais j'ai quand même beaucoup appris en le faisant. J'utilisais SCO Unix LONG AVANT même que le Web existe (oui, je suis si vieux!)) Et expérimenter de cette façon a été inestimable pour mon apprentissage.
Donc, ce que je dis, c'est que si cela ne vous dérange pas de faire des réinstallations en cas de problème, utilisez su ou connectez-vous en tant que root tout ce que vous voulez et configurez/piratez! Vous apprendrez beaucoup de choses en faisant cela.
N'oubliez pas que les conseils qui ont été répétés beaucoup ici ont été réitérés pour une bonne raison: les protocoles de bonnes pratiques ont évolué au fil des décennies au fur et à mesure que compsec a évolué, et vous DEVEZ y faire attention, même en tant qu'utilisateur domestique/unique de votre système . Ce faisant, une bonne hygiène/habitudes sysadmin deviendra une seconde nature pour vous.
Juste quelques pistes de réflexion sur le sujet de su et sudo. Bon piratage!
Hypothèse: c'est votre système et vos données.
Il vous suffit de pondérer le risque d'effacement accidentel de données ou de brique de votre système d'exploitation par rapport à la facilité de faire des choses sans taper Sudo à chaque fois.
Je me connecte régulièrement et je travaille en tant que root sur mes serveurs personnels car Je peux c'est plus facile.
On vous dira que vous pouvez lancer des armes nucléaires si vous ne passez pas par le sacro-saint Sudo mais la réalité est qu'aujourd'hui les gens ont root pouvoirs (*) sur de nombreux appareils (votre TV, votre téléphone, votre grille-pain, votre Windows (comme vous l'avez mentionné)). Linux n'est pas différent ici, même si beaucoup aiment penser le contraire.
BTW UAC n'a pas été modelé sur Sudo car son rôle d'homme est (en plus de rendre votre vie misérable) pour vous assurer que vous verrez quand un malware veut faire des choses en votre nom.
(*) root pouvoirs sont définis comme la capacité de neutraliser des données importantes. L'adage "avec une grande puissance vient de grands problèmes" (ou quoi que ce soit) s'applique.
Si mon hypothèse est fausse alors vous devez toujours pondérer le risque ci-dessus mais il y a plus de variables (votre travail, des photos prises par votre conjoint et stockées sur le même ordinateur portable, ...)