Как я могу узнать, есть ли у меня разрешение на запуск определенной команды?

Есть ли способ определить, имею ли я как обычный пользователь право выдавать команду.

Например; Я хочу проверить, есть ли у меня право на команду выключения, прежде чем я действительно ее выполню.

Что-то вроде следующих команд

-> doIhaveRightToIssue shutdown
-> Yes/No

Самый простой случай - это двоичный исполняемый файл типа gzip. Сначала мы находим исполняемый файл:

$ which gzip
/bin/gzip

Затем мы смотрим на атрибуты этого файла:

$ ls -l /bin/gzip
-rwxr-xr-x 1 root root 98240 oct 27  2014 /bin/gzip

Три x говорят нам, что файл может быть выполнен владельцем (первым root) или кем-либо в группе root(вторым root) и кем-либо еще, соответственно. Таким образом, ваш пользователь может выполнять программу.

Тем не менее, ваш исполняемый файл может быть файлом сценария, который вызывает другие исполняемые файлы внутри. Вы можете выполнять скрипт, но не программы, вызываемые внутри него. Нет никакого способа определить, разрешено ли вашему пользователю делать это, кроме как на самом деле попробовать.

Кроме того, существуют особые случаи, такие как shutdown- это действительно символическая ссылка на базовую утилиту systemctl, которая имеет собственные механизмы, позволяющие определить, разрешено ли вам вызывать ее, и, например, запросить пароль sudo, если вы этого не сделаете. ,

(О whichкоманде: она находит исполняемые файлы в вашем $ PATH, которые вам разрешено выполнять, и сообщает вам, какой из них вы используете, если у вас более одного с таким же именем в $ PATH. Он не находит только исполняемый файл. I используйте его здесь как пример того, где искать разрешение. Тот факт, что whichисполняемый файл уже найден, указывает на то, что у вас есть разрешение на его выполнение.)

С sudo:

$ sudo -l shutdown
/sbin/shutdown

Если у меня не было разрешения, я sudoбуду жаловаться вместо показа команды.

С помощью polkit вы проверяете действие, которое хотите запустить:

$ pkcheck --action-id org.freedesktop.login1.power-off --process $$ -u --enable-internal-agent && echo yes
polkit\56temporary_authorization_id=tmpauthz1
yes

Поиск соответствующего действия - это другой вопрос.

Ты можешь использовать:

test -x $(command -v shutdown) && echo yes || echo no

command -v shutdownвозвращает путь к shutdownкоманде. test -xпроверяет, является ли этот путь исполняемым для вас.

Обратите внимание, что, хотя вы можете выполнить команду, команда все равно может завершиться ошибкой, поскольку у нее недостаточно прав для выполнения задачи. Это распространенный случай в системах Unix-типа, которые вместо ограничения доступа для выполнения команды вместо этого ограничивают доступ к операциям, которые программы могут фактически выполнять.

Ну, иногда это может быть немного сложно ...

Прежде всего, посмотрите на разрешения с ls -l...

 команда группы пользователей owngrpotr
-rwxr-xr-x root bin vim

Если в последнем / третьем триплете есть x («можно выполнить»), то другие - и это означает, что вы - можете выполнить его… Если это скрипт-сценарий или что-то в этом роде, тогда другим понадобится r (» читать тоже могу)

Если у других нет разрешения на выполнение, а есть у группы (второй триплет), вы можете выполнить его, если вы являетесь членом группы - в примере выше, bin . Например, колесная группа часто используется для ограничения того, кто может работать su, поэтому ее могут выполнять только пользователи, принадлежащие к этой группе. Другой пример - создание группы для разработчиков и ограничение выполнения C-компилятора и подобных инструментов для этой группы.

Если после последнего триплета есть завершающий + , это означает, что используются AccessControllLists - это может добавить права на выполнение для дополнительных пользователей и групп.

+++

Даже если вы в состоянии выполнить команду, команда может зависеть от доступа к файлам, каталогам и / или устройствам, к которым у вас нет доступа - это может ограничить то, что вы сможете сделать (вы не сможете делать что-либо).

Наконец, хотя вам может быть разрешено выполнить команду, сама команда может проверить вашу личность и отказать вам в ее использовании, если вы не указаны в config-файле или не являетесь определенными пользователями (например, root ). Например, mountкоманда разрешит root только для монтирования любого устройства - обычным пользователям разрешено монтировать только те устройства, которые указаны как таковые в / etc / fstab ..., которые могут отсутствовать. Если вы не root и пытаетесь что-то монтировать, mountбудете жаловаться и отказываться монтировать устройство. Другой пример sudo, который будет работать для всех, но только пользователям, перечисленным в / etc / sudoers, будет разрешено запускать вещи от имени пользователя root .

Использование which, typeи commandт. Д. - практичное решение, которое будет работать в 99% случаев, но чтобы быть на 100% уверенным, вам придется вручную проверять каждый исполняемый каталог, указанный в вашем $PATH. Многие оболочки (в том числе bash) будут префикс вашей команды с входами от $PATHи попытаться выполнить эти файлы несколько раз, пока они не будут выполнены успешно. Поскольку whichкоманда не может действительно выполнить команду, она не может предсказать, какой файл действительно выберет ваша оболочка.

Например, представьте, у меня есть PATH=/opt/arm/bin:/binоба каталога, содержащие исполняемые файлы, но для разных архитектур. Запуск which ddвернется /opt/arm/bin/dd(при условии, что у меня есть разрешения на его выполнение), так как эта запись на первом месте. Тем не менее, когда я запускаю ddв своей оболочке, /bin/ddбудет выполняться, потому что /opt/arm/bin/ddне удастся запустить. Та же самая ситуация может произойти в случае испорченных двоичных файлов, отсутствующих библиотек и т. Д. В конце концов, нет точного способа узнать, сможете ли вы выполнить команду или нет, кроме попыток.

Другим аспектом является то, что вы считаете «иметь разрешения». Как пользователь, у меня есть разрешения на запуск, rm ~/fileно нет rm /root/file. Опять же, нет общего способа узнать это без ручного осмотра или выдачи команды и наблюдения за результатами.