Comment savoir si j'ai la permission d'exécuter une commande particulière?
Est-il possible de déterminer si, en tant qu'utilisateur ordinaire, j'ai le droit d'émettre une commande?.
Par exemple; Je veux vérifier si j'ai le droit d'émettre la commande shutdown avant de l'exécuter.
Quelque chose comme les commandes suivantes
-> doIhaveRightToIssue shutdown
-> Yes/No
Le cas le plus simple est celui d'un exécutable binaire tel que gzipname__. Tout d'abord, nous localisons l'exécutable:
$ which gzip
/bin/gzip
Ensuite, regardons les attributs de ce fichier:
$ ls -l /bin/gzip
-rwxr-xr-x 1 root root 98240 oct 27 2014 /bin/gzip
Les trois x nous indiquent que le fichier peut être exécuté par le propriétaire (le premier rootname__), ou par n’importe qui du groupe root(deuxième rootname__) et par d’autres personnes, respectivement. Ainsi, votre utilisateur est autorisé à exécuter le programme.
Cependant, votre exécutable peut être un fichier de script qui appelle d'autres exécutables à l'intérieur. Vous pourrez peut-être exécuter le script, mais pas les programmes appelés à l'intérieur. Il n’existe aucun moyen de déterminer si votre utilisateur est autorisé à le faire, si ce n’est réellement l’essayer.
Ensuite, il y a des cas spéciaux comme shutdown- il s'agit en réalité d'un lien symbolique vers un utilitaire principal appelé systemctlname__, qui possède ses propres mécanismes pour déterminer si vous êtes autorisé à l'appeler et vous demander votre mot de passe Sudo si vous ne le faites pas. par exemple.
(À propos de la commande whichname__: elle localise les exécutables de votre $ PATH que vous êtes autorisé à exécuter et vous indique celui que vous utilisez si vous en avez plusieurs portant le même nom dans $ PATH. Elle ne localise aucun exécutable. Je l’utilise ici comme exemple d’emplacement où rechercher l’autorisation. Le fait que whichtrouve le fichier exécutable indique déjà que vous avez l’autorisation de l’exécuter.)
Avec Sudo:
$ Sudo -l shutdown
/sbin/shutdown
Si je n'avais pas la permission, Sudo se plaindra au lieu d'afficher la commande.
Avec polkit, vous recherchez l'action que vous souhaitez exécuter:
$ pkcheck --action-id org.freedesktop.login1.power-off --process $$ -u --enable-internal-agent && echo yes
polkit\56temporary_authorization_id=tmpauthz1
yes
Trouver l'action pertinente est une question différente.
Vous pouvez utiliser:
test -x $(command -v shutdown) && echo yes || echo no
command -v shutdown renvoie le chemin d'accès à la commande shutdown. test -x vérifie si ce chemin est exécutable pour vous.
Notez que bien que vous puissiez pouvoir exécuter la commande, celle-ci peut toujours échouer car elle ne dispose pas des autorisations nécessaires pour exécuter la tâche. C'est le cas habituel sur les systèmes de type Unix, qui plutôt que de restreindre l'accès pour exécuter une commande, limitent l'accès aux opérations que les programmes peuvent réellement effectuer.
Eh bien, cela peut être un peu difficile parfois ...
Tout d’abord, examinez les autorisations avec ls -l...
commande du groupe d'utilisateurs owngrpotr - rwxr-xr-x racine bin vim
Si le dernier/troisième triplet a un x ("peut exécuter"), alors autres - et cela signifie que vous - peut l'exécuter ... Si c'est un script shell ou quelque chose comme ça, alors les autres auraient besoin de r (" peut lire ") aussi.
Si les autres n'ont pas la permission d'exécution mais le groupe (le second triplet) fait, alors vous pouvez l'exécuter si vous êtes membre du groupe - dans l'exemple ci-dessus, bin . Par exemple, la roue - est souvent utilisée pour limiter le nombre de personnes pouvant exécuter su, de sorte que seuls les utilisateurs appartenant à ce groupe puissent l'exécuter. Un autre exemple est de créer un groupe pour développer et de limiter l’exécution du compilateur C et de tels outils à ce groupe.
S'il y a un + après le dernier triplet, cela signifie que les listes AccessControllLists sont utilisées. Cela peut ajouter des droits d'exécution à d'autres utilisateurs et groupes.
+++
Même si vous êtes capable d’exécuter la commande, celle-ci peut dépendre de l’accès aux fichiers, répertoires et/ou périphériques auxquels vous n’avez pas accès - ceci peut limiter vos possibilités (vous risquez de ne pas pouvoir faire n'importe quoi).
Enfin, bien que vous puissiez être autorisé à exécuter une commande, la commande elle-même peut vérifier votre identité et refuser de vous laisser l’utiliser, à moins que vous ne soyez répertorié dans un fichier de configuration ou que certains utilisateurs ne soient pas enregistrés (par exemple. racine ). Par exemple, la commande mount permettra uniquement root de monter tout périphérique - les utilisateurs normaux ne sont autorisés à monter que les périphériques répertoriés comme tels dans/etc/fstab .. qui peut être nul. Si vous n'êtes pas root et essayez de monter quelque chose, mount se plaindra et refusera de monter le périphérique. Un autre exemple est Sudo, qui fonctionnera pour tout le monde, mais seuls les utilisateurs répertoriés dans/etc/sudoers seront autorisés à exécuter des tâches en tant que root .
Utiliser whichname__, typename__, commandetc. est une solution pratique qui fonctionnera dans 99% des cas, mais pour être sûr à 100%, vous devrez inspecter manuellement tous les répertoires exécutables répertoriés dans votre $PATH. De nombreux shells (dont bashname__) préfixeront votre commande avec des entres à partir de $PATH et essaieront d’exécuter ces fichiers à plusieurs reprises jusqu’à ce qu’ils réussissent. Étant donné que whichne peut pas réellement exécuter la commande, il lui est impossible de prédire le fichier que votre shell va réellement sélectionner.
Par exemple, imaginez que j'ai PATH=/opt/arm/bin:/bin, les deux répertoires contenant des fichiers exécutables, mais pour des architectures différentes. Si vous exécutez which dd, vous obtiendrez /opt/arm/bin/dd (en supposant que je suis autorisé à l'exécuter), car cette entrée est la première. Cependant, lorsque j'exécute dddans mon shell, /bin/dd sera exécuté, car /opt/arm/bin/dd ne pourra pas s'exécuter. La même situation peut se produire en cas de fichiers binaires corrompus, de bibliothèques manquantes, etc. En fin de compte, il n’existe aucun moyen sûr de savoir si vous pourrez exécuter une commande ou non, mis à part essayer.
Un autre aspect est ce que vous considérez "avoir des autorisations". En tant qu'utilisateur, j'ai l'autorisation d'exécuter rm ~/file mais pas rm /root/file. Encore une fois, il n’existe aucun moyen général de le savoir sans inspection manuelle, ni commande et observation des résultats.