Un programme peut-il dire qu'il est exécuté sous sudo ?

Solution 1 :

Oui, il y a 4 variables d'environnement définies lorsqu'un programme s'exécute sous sudo :

$ sudo env |grep SUDO
SUDO_COMMAND=/usr/bin/env
SUDO_USER=tal
SUDO_UID=501
SUDO_GID=20

Notez que ceux-ci peuvent être truqués en les définissant simplement. Ne leur faites pas confiance pour quoi que ce soit de critique.

Par exemple :dans ce programme, nous devons dire à l'utilisateur d'exécuter un autre programme. Si l'actuel a été exécuté avec sudo, l'autre le sera aussi.

#!/bin/bash

echo 'Thank you for running me.'

if [[ $(id -u) == 0 ]]; then
  if [[ -z "$SUDO_COMMAND" ]]; then
    echo 'Please now run: next_command'
  else
    echo 'Please now run: sudo next_command'
  fi
else  echo 'Error: Sadly you need to run me as root.'
  exit 1
fi

Notez qu'il ne teste une variable SUDO_* que s'il peut d'abord prouver qu'il s'exécute en tant que root. Même dans ce cas, il ne l'utilise que pour modifier un texte utile.

Solution 2 :

Cela ne répond pas directement à la question, mais je ne pense pas que la bonne question soit posée ici. Il me semble que le demandeur veut un programme qui agira vraisemblablement différemment s'il a certaines autorisations ou non, mais je dirais que vérifier sudo n'est pas le moyen de le faire. Tout d'abord, de nombreux systèmes peuvent ne pas implémenter un "sudo", il n'est en aucun cas requis sous Linux ou de nombreux Unix.

Par exemple, un utilisateur peut déjà être connecté en tant que root, ce qui rend le sudo absurde ou peut-être que le système a des utilisateurs non root qui ont encore la capacité d'effectuer la tâche administrative que le programme peut souhaiter effectuer. Enfin, peut-être que le système n'a pas du tout de racine ou de sudo et utilise à la place un système de contrôle d'accès obligatoire avec différentes capacités et aucun superutilisateur catch all vers sudo. Ou l'utilisateur peut être sudo, mais dans un compte qui a -moins- d'autorisations que son propre compte pour des raisons de sécurité (j'exécute souvent du code non approuvé avec un utilisateur temporaire non privilégié qui ne peut écrire que sur des disques virtuels afin de supprimer, pas d'augmenter mes autorisations ). C'est globalement une mauvaise idée de supposer un modèle d'autorisations spécifique comme sudo ou l'existence de root ou de supposer qu'un utilisateur sudo dispose de privilèges particuliers.

Si vous voulez savoir si vous avez des autorisations pour effectuer une opération, la meilleure façon est généralement d'essayer et de le faire, puis vérifiez errno pour les problèmes d'autorisations si elle échoue ou s'il s'agit d'une opération en plusieurs étapes qui doit échouer ou réussir. vous pouvez vérifier si une opération fonctionnera avec des fonctions telles que la fonction d'accès POSIX (attention aux conditions de concurrence possibles ici si les autorisations sont activement modifiées)

Si en plus vous avez besoin de connaître le véritable utilisateur derrière le sudo, vous pouvez utiliser la fonction getlogin qui devrait fonctionner pour toute session interactive avec un terminal sous-jacent et vous permettrait par exemple de trouver qui exécute 'vraiment' la commande pour l'audit ou de trouver le répertoire personnel de l'utilisateur réel pour enregistrer les journaux.

Enfin, si ce que vous voulez vraiment, c'est savoir si un utilisateur a un accès root (toujours une mauvaise idée mais moins spécifique à l'implémentation), vous pouvez utiliser getuid pour vérifier un uid de 0 et donc root.

Solution 3 :

Deux mécanismes peuvent être utilisés.

• La vérification des variables d'environnement peut être truquée dans les deux cas, mais c'est la plus simple à faire. growisofs n'aime pas fonctionner sous SUDO, donc j'ai annulé les variables SUDO dans les scripts où je l'utilise. Il peut être truqué dans l'autre sens. (La variable SUDO est également transportée dans l'environnement pour les scripts exécutés sous les commandes at et batch.)
• Une autre façon de voir si vous exécutez sous sudo est de parcourir la liste des processus depuis votre processus parent jusqu'à la recherche de sudo. Il serait difficile de cacher que vous utilisiez sudo de cette façon, mais c'est plus complexe. Il est toujours possible de faire semblant que vous utilisez sudo.

Il est plus courant de vérifier si vous exécutez en tant qu'utilisateur approprié. Le id La commande peut être utilisée pour cela. Le script de TomOnTime utilise le id commande pour déterminer si sudo peut être nécessaire pour exécuter la commande suivante.

Solution 4 :

Vous pouvez comparer l'ID utilisateur effectif et réel.

Cela ne signifie pas strictement qu'il exécute undo sudo (peut également être défini), mais indique que le programme a plus de droits que ce à quoi l'utilisateur peut s'attendre (par exemple, dans un programme qui est normalement exécuté sans ces droits, mais qui doit être exécuté avec eux lors de l'installation ou pour installer des mises à jour. Ensuite, vous pouvez l'utiliser pour donner des commentaires d'avertissement à ce sujet).

Solution 5 :

Vous pouvez vérifier la variable UID (EUID) effective, comme suit :

if [[ $EUID -eq 0 ]]; then
    echo "running as root"
else
    echo "not running as root"
fi