web-dev-qa-db-fra.com

Quelle est la différence entre Sudo et Changing to root

Si je délivre un

Sudo /bin/bash`  
[Sudo] password for mark:
cmp -bl /dev/blah1 /dev/blah2

et en utilisant

Sudo cmp -bl /dev/blah1 /dev/blah2

puis vous connecter en tant que root?

Je ne vois pas ce qui est différent, si plusieurs lignes de commande sont émises, alors rooting IMHO semble l’option logique qui consiste à taper le préfixe Sudo sur les lignes de commande.

J'ai vu Sudo -i utilisé pour se connecter à root, qui fonctionnait auparavant, mais la semaine dernière, il génère une erreur.

** EDIT **

Je me suis connecté en tant que root, j'ai lancé la commande

mark@mark-zotac:~$ Sudo cmp -bl /dev/sda "/media/mark/Seagate Expansion Drive/SSD/ssd.img"
[Sudo] password for mark: 
mark@mark-zotac:~$

Il a fonctionné, a pris environ 30 minutes, mais a généré zero comme dans nothing. Il ne me reste aucune indication d'échec ou de succès ... Alors, comment savoir si le résultat de la comparaison a été un succès?

command-lineroot
5
Mark Giblin

Ce qui suit a été extrait directement de la page du wiki de la communauté sur la racine Sudo .

Sudopermet à l'utilisateur d'agir en tant que root sans connexion root; Il est plus sûr d'utiliser Sudoau lieu de vous connecter en tant que root.

Avantages et inconvénients

Avantages de l'utilisation de Sudoname__

Ubuntu a de nombreux avantages à laisser les connexions root désactivées par défaut, notamment:

  1. L'installateur a moins de questions à poser.
  2. Les utilisateurs n'ont pas besoin de se souvenir d'un mot de passe supplémentaire pour une utilisation occasionnelle (c'est-à-dire le mot de passe root). S'ils le faisaient, ils l'oublieraient (ou enregistrez-le de manière non sécurisée, permettant à quiconque de s'introduire facilement dans leur système).
  3. Cela évite la connexion interactive "Je peux tout faire" par défaut. Un mot de passe vous sera demandé avant tout changement majeur, ce qui devrait vous faire réfléchir aux conséquences de ce que vous faites.
  4. Sudo ajoute une entrée de journal de la ou des commandes exécutées (dans /var/log/auth.log). Si vous vous trompez, vous pouvez revenir en arrière et voir quelles commandes ont été exécutées.
  5. Sur un serveur, chaque pirate essayant de s’imposer brutalement sait qu’il dispose d’un compte appelé root et l’essaye en premier. Ce qu'ils ne savent pas, c'est quels sont les noms d'utilisateur de vos autres utilisateurs. Comme le mot de passe du compte root est verrouillé, cette attaque n'a plus de sens, puisqu'il n'y a pas de mot de passe à craquer ou à deviner.
  6. Permet un transfert facile des droits d'administrateur en ajoutant et en supprimant des utilisateurs de groupes. Lorsque vous utilisez un seul mot de passe root, le seul moyen de désautoriser les utilisateurs consiste à modifier le mot de passe root.
  7. Sudopeut être configuré avec une politique de sécurité beaucoup plus fine.
  8. Le mot de passe du compte racine n'a pas besoin d'être partagé avec toutes les personnes devant effectuer un type de tâche administrative sur le système (voir la puce précédente).
  9. L'authentification expire automatiquement après une courte période (que vous pouvez définir aussi peu que vous le souhaitez ou 0). Par conséquent, si vous quittez le terminal après avoir exécuté des commandes en tant que root à l'aide de Sudoname__, vous ne laisserez pas un terminal racine ouvert indéfiniment.

Inconvénients de l'utilisation de Sudo

Bien que, pour les ordinateurs de bureau, l'utilisation de Sudo présente de grands avantages, il convient de noter certains problèmes:

  1. La redirection de la sortie des commandes exécutées avec Sudo nécessite une approche différente. Par exemple, considérons Sudo ls > /root/somefile ne fonctionnera pas, car c’est le shell qui configure les redirections qui essaient d’écrire dans ce fichier, et non la commande en cours d’exécution avec l’autorisation root. Vous pouvez utiliser

    ls | Sudo tee -a /root/somefile

    ajouter, ou

    ls | Sudo tee /root/somefile

    pour écraser le contenu. Vous pouvez également passer toute la commande à un processus Shell exécuté sous Sudo pour que le fichier soit écrit avec les autorisations root, tel que

    Sudo sh -c "ls > /root/somefile"
  2. Dans de nombreux environnements de bureau, le SEUL utilisateur local sur un système est root. Tous les autres utilisateurs sont importés à l'aide de techniques NSS telles que nss-ldap. Pour installer un poste de travail ou le réparer, en cas de défaillance du réseau lorsque nss-ldap est endommagé, vous devez utiliser la racine. Cela a tendance à laisser le système inutilisable à moins d'être fissuré. Un utilisateur local supplémentaire ou un mot de passe root activé est nécessaire ici. Le compte d'utilisateur local doit avoir son $ HOME sur un disque local, et non sur NFS (ou tout autre système de fichiers en réseau), et un .profile/.bashrc qui ne ne faites pas référence à des fichiers sur des montages NFS. C'est généralement le cas pour root, mais si vous ajoutez un compte de secours non root, vous devrez prendre ces précautions manuellement. Toutefois, l’avantage d’utiliser un utilisateur local avec Sudoest que les commandes peuvent être facilement suivies, comme indiqué dans les avantages ci-dessus.

Idées fausses sur la connexion root

  1. Sudon'est-il pas moins sécurisé que suname__?

    Le modèle de sécurité de base est le même et ces deux systèmes partagent donc leurs principales faiblesses. Tout utilisateur qui utilise suou Sudodoit être considéré comme un utilisateur privilégié. Si le compte de cet utilisateur est compromis par un attaquant, celui-ci peut également obtenir des privilèges root à son prochain passage. Le compte d'utilisateur est le maillon faible de cette chaîne et doit donc être protégé avec le même soin que root.

    Sur un niveau plus ésotérique, Sudofournit certaines fonctionnalités qui encouragent différentes habitudes de travail, ce qui peut avoir un impact positif sur la sécurité du système. Sudoest généralement utilisé pour exécuter une seule commande, alors que suest généralement utilisé pour ouvrir un shell et exécuter plusieurs commandes. L'approche Sudoréduit la probabilité qu'un shell racine soit laissé ouvert indéfiniment et encourage l'utilisateur à minimiser son utilisation des privilèges root.

  2. Je ne pourrai pas passer en mode mono-utilisateur!

    Le programme sulogin dans Ubuntu est corrigé pour gérer le cas par défaut d’un mot de passe root verrouillé.

  3. Je peux obtenir un shell racine à partir de la console sans entrer de mot de passe!

    Vous devez entrer votre mot de passe.

    Les utilisateurs de la console ont accès au chargeur de démarrage et peuvent obtenir des privilèges d'administrateur de différentes manières au cours du processus de démarrage. Par exemple, en spécifiant un autre programme init (8). Les systèmes Linux ne sont généralement pas configurés pour être sécurisés sur la console et des étapes supplémentaires (par exemple, définir un mot de passe root, un mot de passe du chargeur de démarrage et un mot de passe du BIOS) sont nécessaires pour le faire. Notez que les utilisateurs de la console ont généralement un accès physique à la machine et peuvent donc la manipuler d'autres manières.

Notes spéciales sur le sudo et les coquillages

Aucune des méthodes ci-dessous n'est suggérée ou supportée par les concepteurs d'Ubuntu.

Veuillez ne pas le suggérer à d'autres personnes, sauf si vous êtes personnellement disponible 24h/24 et 7j/7 pour aider l'utilisateur s'il rencontre des problèmes résultant de l'exécution d'un shell en tant que root.

Pour démarrer un shell root (c'est-à-dire une fenêtre de commande dans laquelle vous pouvez exécuter des commandes root), en lançant l'environnement et les scripts de connexion de la racine, utilisez:

  • Sudo -i (similaire à Sudo su -, vous donne la configuration de l'environnement root)

Pour démarrer un shell racine, tout en conservant l'environnement du shell actuel, utilisez:

  • Sudo -s (similaire à Sudo su)

Voici un bref aperçu de certaines des différences entre suname__, su - et Sudo -{i,s}

                HOME=/root      uses root's PATH     env vars
Sudo -i         Y               Y[2]                 N
Sudo -s         N               Y[2]                 Y
Sudo bash       N               Y[2]                 Y
Sudo su         Y               N[1]                 Y

[1] PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games  (probably set by /etc/environment)

[2] PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
15
Faizan Akram Dar

La question n'a rien à voir avec la différence entre Sudo et su.

La page de manuel de cmp se lit comme suit:

L'utilitaire cmp compare deux fichiers de n'importe quel type et écrit les résultats dans la sortie standard. Par défaut, cmp est muet si les fichiers sont identiques. s’ils diffèrent, l’octet et le numéro de ligne auxquels la première différence s’est produite sont signalés.

Donc, pas de sortie signifie que les deux fichiers sont identiques.

4
Rmano