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

44

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. Surfer sur le superutilisateur Je ne peux déterminer aucune raison possible pour que ce soit le cas, et en confirmation, lorsque je lance:

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 laquelle sudo se comporterait différemment que root pour l'installation de logiciels sur un serveur?

linux sudo root Ranger
la source
2
Je pense que tu devrais le lui renvoyer. Comme d'autres l'ont montré, il y a une myriade de façons de gagner des racines en utilisant sudo et s'il ne peut pas vous donner une raison concrète de la raison pour laquelle sudo est insuffisant, il n'a alors pas de jambe sur laquelle se tenir.
Garrett
1
L’environnement et les sous-commandes me viennent à l’esprit. Je pense que Hastur a fait un bon travail avec l’environnement et Jayen a fait du bon travail avec les sous-commandes, la tuyauterie et la redirection.
jww
2
Garrett a un bon point, mais avant de me lancer dans un concours potentiel d'irritation, je demanderais au membre du support: avez-vous essayé les deux méthodes et a-t-il échoué? Il a peut-être été sur la route de l'échec avec sudoet les scripts tels que les scripts sont actuellement écrits. Si tel est le cas, la réponse de sds pourrait être plus utile pour vous: sudo su -.
jww

Réponses:

34

Cela dépend fortement de la façon dont vous appelez votre programme avec sudoou 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 qui est lancé avec une autre option peut voir différents $PATH, $HOME, sa coquille peut lire différents .bashrc, .profileet les variables de l' environnement. Il lit le fichier lié à la $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 répertoire $PATHet, en conséquence, un script peut exécuter une commande, par exemple in à la /home/$USER/binplace de celle du chemin attendu de la racine.

Vous pouvez exécuter le programme sous sudo -icar vous avez été connecté en tant que root su -, mais vous pouvez avoir un comportement différent si vous l'exécutez avec sudo MyCommandou 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 à celui auquel l'utilisateur s'attendait s'il était connecté directement .

De l'homme sudo

-i , --login
Exécuter 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é. sudotente de passer au répertoire de base de cet utilisateur avant d'exécuter le shell. 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.

Hastur
la source
Très bonne réponse. Je suis toujours un novice chez Linux, mais est-ce une autre différence que ce que vous pouvez faire en utilisant sudopeut être limité par des autorisations dans le fichier sudoers par opposition à faire des choses en tant que root n’a pas ces limitations? La dernière citation de bloc implique peut-être cela, mais si je comprends bien, cela semble être une différence de fond autre que l'environnement (ou peut-être à cause de l'environnement?).
fixer1234
23

Si vous avez un sudoaccès complet , vous pouvez rootutiliser sudo su -, le point de sécurité est donc devenu inutile.

En effet, il existe un moyen de discerner la différence entre un programme exécuté en tant rootque programme et un programme exécuté sous sudo-utilisant getuidvs geteuid- mais c’est une astuce artificielle. Pourquoi un système de patch ferait-il cela?

sds
la source
5
En parlant de su -, il peut vouloir utiliser sudo -ipour avoir le même environnement que lorsqu’il se connecte directement.
Cristian Ciupitu
2
Si vous utilisez par exemple, sudo myscriptvous conserverez les variables d'environnement $ PATH et du shell dans lequel vous vous trouvez. Si vous courez avec sudo -i myscriptvous, courez comme si vous vous connectiez en tant que root. Voir la réponse avec notre _zoo d'appels :-) _
Hastur
1
Je pense qu'il est important de souligner que les variables environnementales ne sont peut-être pas configurées de la même façon sudoque si vous vous connectez en tant que root
secretformula
1
@dmanexe: sudo n'est pas synonyme de super-utilisateur, mais de "changer d'utilisateur". su et sudo peuvent être utilisés pour basculer vers n'importe quel utilisateur plutôt que simplement le superutilisateur. En outre, il n'y a rien de pseudo à propos de sudo, vous obtenez réellement la racine réelle lorsque vous exécutez sudo, rien de faux. Notez que la magie de sudo vient vraiment du bit d’autorisation setuid.
Lie Ryan
2
sds, @CharlesDuffy: L’idée que le sudo et le su, geteuid()et getuid()d’être différents, est un mythe. su et sudo remplacent les ID utilisateur réel et effectif par ceux de l'utilisateur cible avant d'exécuter la commande ou le shell spécifié, sauf dans le cas très inhabituel où vous les avez explicitement configurés pour qu'ils se comportent autrement. Vous pouvez le vérifier (pour sudo) en exécutant sudo id -uet sudo id -ru(les deux affichent 0), en lisant sudo (8) (sous COMMAND EXECUTION ) ou en écrivant un programme de test .
7

Comme vous le remarquez @Hastur, il existe quelques différences si vous obtenez 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.fileoù patchest exécuté en tant que root, mais ce <n’est pas le cas (la tuyauterie à partir d’un fichier).

Jayen
la source
1
Droite: le point de vue pratique offre souvent des astuces difficiles à détecter uniquement à partir des pages de manuel. Pour surmonter une situation similaire, vous devez obligatoirement faire plus de gymnastique [:-)], par exemple, écrire quelque chose comme sudo /bin/bash -c "./patch -p0 < /root/patch". Encore plus délicat est le cas lorsque vous utilisez la redirection pour créer un fichier >. Dans un premier temps, vous créerez un fichier appartenant à l'utilisateur uniquement si vous avez le droit d'écrire dans le répertoire final. De cette manière, vous créerez un fichier appartenant à root ... la face cachée de Unix ;-)
Hastur
1

Je crois que lors de l’utilisation de l’accès sudo, un fichier journal est créé, mais lorsqu’il s’exécute directement via l’accès root, il n’existe

Ashley Redman BSc
la source
0

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 le sudo en général ...

meredithkm
la source