web-dev-qa-db-fra.com

Sudo vs root; des différences réelles?

Je travaille avec un membre du support technique pour un produit, et il insiste sur le fait que je dois être root pour installer une série de correctifs et que Sudo ne fonctionnera pas. il ne fournit aucune raison mais semble très ferme dans ses convictions. Navigation sur le super-utilisateur Je ne peux déterminer aucune raison possible pour que ce soit le cas, et en confirmation, lorsque j'exécute:

Sudo -l

Je reçois:

...
User [MY USERNAME] may run the following commands on this Host:
    (ALL) ALL

Obtenir l'accès à partir de l'équipe Linux/serveur pour être réellement root n'est pas un processus immédiat, si je comprends bien, je préférerais donc les installer moi-même.

Existe-t-il une raison pratique pour que Sudo se comporte différemment que root pour l'installation de logiciels sur un serveur?

linuxcommand-linesudoroot
43
Nex Terren

Cela dépend fortement de la façon dont vous appelez votre programme avec Sudo ou su.
Par exemple. sur le système sur lequel je suis en ce moment:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. Sudo -i        (root)   root  root  [1]
 2. Sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. Sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. Sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. Sudo su -      (root)   root  root  [1]

Où [1] =/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Env = Les variables d'environnement sont réinitialisées pour 1 et 5, à partir de $ USER dans 2,3,4.

Ainsi, un script ou un programme lancé avec une option différente peut afficher différents $PATH, $HOME, son shell peut lire différentes variables .bashrc, .profile et environnement. Il lit le fichier lié au $HOME. Chaque utilisateur peut modifier son environnement de manière différente (variables, $PATH, .bashrc, .profile, .bash_profile, alias ...). En particulier, un utilisateur peut avoir un ordre différent des répertoires dans son $PATH et, par conséquent, un script peut exécuter une commande, par exemple. dans /home/$USER/bin à la place de celui du chemin attendu de la racine.

Vous pouvez exécuter le programme sous Sudo -i car vous avez été connecté en tant que root avec su -, mais vous pouvez avoir un comportement différent si vous l’exécutez avec Sudo MyCommand ou avec su -c MyCommand.

De man su:

Dans la partie description:
L'environnement actuel est transmis au nouveau shell . La valeur de $ PATH est réinitialisée sur/bin:/usr/bin pour les utilisateurs normaux ou/sbin:/bin:/usr/sbin:/usr/bin pour le superutilisateur
...
Dans la partie options:
- , -l, --login
Fournit un environnement similaire à à quoi l'utilisateur s'attendrait s'il était connecté directement .

De l'homme Sudo

- i , --login
Exécutez le shell spécifié par l'entrée de la base de données de mots de passe de l'utilisateur cible en tant que shell de connexion. Cela signifie que les fichiers de ressources spécifiques à la connexion, tels que .profile ou .login, seront lus par le shell. Si une commande est spécifiée, elle est transmise au shell pour exécution via l'option -c du shell. Si aucune commande n'est spécifiée, un shell interactif est exécuté. Sudo tente de passer au répertoire de base de cet utilisateur avant d'exécuter l'environnement de ligne de commande. La commande est exécutée dans un environnement similaire à celui qu'un utilisateur recevrait lors de la connexion . La section Environnement de commande du manuel sudoers (5) explique en détail comment l'option -i affecte l'environnement dans lequel une commande est exécutée lorsque la stratégie sudoers est utilisée.

33
Hastur

Si vous disposez d'un accès complet Sudo , vous pouvez devenir root à l'aide de Sudo su -, de sorte que le point de sécurité est sans objet.

En effet, il existe un moyen de distinguer la différence entre un programme exécuté sous root et un programme exécuté sous Sudo - en utilisant getuid vs geteuid - mais c'est une astuce artificielle. Pourquoi un système de patch ferait-il cela?

23
sds

Comme vous le remarquez @Hastur, il existe quelques différences si vous avez un shell racine.

Si vous n'obtenez pas un shell racine, il y a plus de différences. Le membre du support technique peut avoir déjà essayé de faire des choses comme Sudo patch -p0 < /root/patch.file, où patch est exécuté en tant que root, mais pas < (la tuyauterie à partir d'un fichier).

7
Jayen

Je crois que lors de l’utilisation de l’accès Sudo, un fichier journal est créé, mais il n’existe pas d’exécution directe par le biais de l’accès root.

1
Ashley Redman BSc

Cela dépend du degré de finesse de votre accès racine. Si vous avez plusieurs utilisateurs qui effectuent différentes tâches sur un système, alors Sudo serait plus idéal. Un exemple que j'utilise fréquemment est la nécessité de redémarrer une application ou une base de données. La sécurité est toujours mieux faite avec le moins de privilèges. J'utilise des groupes et n'autorise que ces groupes à effectuer des actions explicites. Un bon livre décrivant ce processus est "Maîtrise Sudo: Contrôle de l'accès des utilisateurs réels". En fait, c’est un bon livre sur Sudo en général ...

0
meredithkm