Existe-t-il un moyen d'identifier 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 d' arrêt avant de la lancer.
Quelque chose comme les commandes suivantes
-> doIhaveRightToIssue shutdown
-> Yes/No
Réponses:
Le cas le plus simple est celui d'un exécutable binaire comme gzip. Tout d'abord, nous localisons l'exécutable:
$ which gzip
/bin/gzip
Ensuite, nous 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 root), ou n'importe qui dans le groupe root(le deuxième root) et n'importe qui d'autre, respectivement. Votre utilisateur est donc 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'y a aucun moyen de déterminer si votre utilisateur est autorisé à le faire, à part l'essayer.
Ensuite, il y a des cas spéciaux comme shutdown- c'est vraiment un lien symbolique vers un utilitaire de base appelé systemctl, qui a ses propres mécanismes pour déterminer si vous êtes autorisé à l'appeler, et pour vous demander votre mot de passe sudo si vous ne le faites pas, par exemple .
(À propos de la whichcommande: cela localise les exécutables dans votre $ PATH que vous êtes autorisé à exécuter et vous indique celui que vous utilisez si vous en avez plusieurs avec le même nom dans $ PATH. Il ne localise pas n'importe quel exécutable. I utilisez-le ici comme exemple de recherche de l'autorisation. Le fait de whichtrouver l'exécutable indique déjà que vous êtes autorisé à l'exécuter.)
whichLa commande doit être suffisante pour les fichiers qui résident dans l'un des répertoires ajoutés à la $PATHvariable. Par exemple, faire sudo chmod 700 /bin/nanoou les sudo chmod 744 nanocauses whichpour produire aucune sortie. Pour les scripts locaux, qui résident ailleurs que dans l'un des PATHrépertoires, ls -lou les statappels feront l'affaire. Bonne réponse, mais veuillez ajouter cette information à votre message
stat -c '%a' /bin/gzippour obtenir 755par exemple.
Avec sudo:
$ sudo -l shutdown
/sbin/shutdown
Si je n'ai pas eu l'autorisation, sudoje me plaindrai au lieu de montrer la commande.
Avec polkit, vous vérifiez 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.
sudo -lmême si vous n'êtes pas un sudoer - c'est tout l'intérêt de -l- pour vous dire si vous pouvez exécuter une commande avec sudo.
Vous pouvez utiliser:
test -x $(command -v shutdown) && echo yes || echo no
command -v shutdownrenvoie le chemin d'accès à la shutdowncommande. test -xvérifie si ce chemin vous est exécutable.
Notez que bien que vous puissiez exécuter la commande, la commande peut toujours échouer car elle ne dispose pas des autorisations suffisantes pour exécuter la tâche. C'est le cas commun sur les systèmes de type Unix qui, plutôt que de restreindre l'accès pour exécuter une commande, restreignent l'accès aux opérations que les programmes peuvent réellement faire.
alias shutdown="shutdown now"?
$(which shutdown)ou $(shopt -u expand_aliases && command -v shutdown). Ce problème n'apparaît cependant qu'en mode interactif.
Ça peut être parfois un peu difficile ...
Tout d'abord, regardez les autorisations avec ls -l...
Commande de groupe d'utilisateurs owngrpotr -rwxr-xr-x racine bin vim
Si le dernier / troisième triplet contient un x ("peut s'exécuter"), alors d' autres - et cela signifie que vous - pouvez l'exécuter ... Si c'est un script shell ou quelque chose comme ça, alors d' autres auraient besoin de r (" peut également lire ").
Si d' autres n'ont pas la permission d'exécution mais que le groupe (le deuxième triplet) le fait, vous pouvez l'exécuter si vous êtes membre du groupe - dans l'exemple ci-dessus, bin . Par exemple, le groupe de roues est souvent utilisé pour limiter les personnes pouvant s'exécuter su, de sorte que seuls les utilisateurs appartenant à ce groupe pourraient l'exécuter. Un autre exemple consiste à créer un groupe pour les développeurs et à limiter l'exécution du compilateur C et de ces outils à ce groupe.
S'il y a un signe de fin + après le dernier triplet, cela signifie que AccessControllLists est utilisé - cela peut ajouter des droits d'exécution à des utilisateurs et des groupes supplémentaires.
+++
Même si vous êtes en mesure d'exécuter la commande, la commande peut dépendre de l'accès aux fichiers, répertoires et / ou périphériques auxquels vous n'avez pas accès - cela peut limiter ce que vous pourrez faire (vous ne pourrez peut-être pas 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 sauf si vous êtes répertorié dans un fichier de configuration ou si vous êtes certains utilisateurs (par exemple, root ). Par exemple, la mountcommande n'autorisera que root à monter n'importe quel périphérique - les utilisateurs normaux ne sont autorisés qu'à monter des périphériques répertoriés comme tels dans / etc / fstab ... qui peuvent ne pas en être. Si vous n'êtes pas root et essayez de monter quelque chose, vous vous mountplaindrez et refuserez de monter l'appareil. Un autre exemple est sudo, qui s'exécutera pour n'importe qui, mais seuls les utilisateurs répertoriés dans / etc / sudoers seront réellement autorisés à exécuter les choses en tant que root .
L' utilisation which, type, commandetc. , est une solution pratique qui fonctionne dans 99% des cas, mais pour être 100% sûr vous devrez inspecter manuellement chaque répertoire exécutable répertorié dans votre $PATH. De nombreux shells (y compris bash) préfixeront votre commande avec entres from $PATHet tenteront d'exécuter ces fichiers à plusieurs reprises jusqu'à ce qu'ils réussissent. Puisqu'il whichne peut pas vraiment exécuter la commande, il lui est impossible de prédire quel fichier votre shell va vraiment choisir.
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. L'exécution which ddreviendra /opt/arm/bin/dd(en supposant que j'ai les autorisations pour l'exécuter), car cette entrée vient en premier. Cependant, lorsque je lance dddans mon shell, /bin/ddsera exécuté, car /opt/arm/bin/ddne fonctionnera pas. La même situation peut se produire en cas de binaires corrompus, de bibliothèques manquantes, etc. En fin de compte, il n'y a aucun moyen sûr de savoir si vous pourrez exécuter une commande ou non, à part essayer.
Un autre aspect est ce que vous considérez comme "avoir des autorisations". En tant qu'utilisateur, j'ai des autorisations pour exécuter rm ~/filemais pas rm /root/file. Encore une fois, il n'y a aucun moyen général de savoir cela sans inspection manuelle, ou émission de la commande et observation des résultats.
sudo) et de découvrir. Les commandes en mode texte peuvent avoir besoinsudoet les commandes graphiques peuvent avoir besoingksudo. Vous pouvez également vérifier où la commande est installéewhich command. Si dans/sbinou/usr/sbin- vous pouvez vous attendre à ce que la commande ait besoin desudoougksudo.