Есть ли способ определить, имею ли я как обычный пользователь право выдавать команду.
Например; Я хочу проверить, есть ли у меня право на команду выключения, прежде чем я действительно ее выполню.
Что-то вроде следующих команд
-> 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исполняемый файл уже найден, указывает на то, что у вас есть разрешение на его выполнение.)
whichКоманда должна быть достаточной для тех файлов, которые находятся в одном из каталогов, добавляемых в $PATHпеременную. Например, выполнение sudo chmod 700 /bin/nanoили sudo chmod 744 nanoприводит whichк выводу без вывода. Для локальных сценариев, которые находятся где-то, кроме одного из PATHкаталогов, ls -lили statвызовы добьются цели. Хороший ответ, но, пожалуйста, добавьте эту информацию в свой пост
stat -c '%a' /bin/gzipчтобы получить 755.
С 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
Поиск соответствующего действия - это другой вопрос.
sudo -lдаже если вы не sudoer - в этом весь смысл -l- чтобы сказать вам, можете ли вы запустить команду с sudo.
Ты можешь использовать:
test -x $(command -v shutdown) && echo yes || echo no
command -v shutdownвозвращает путь к shutdownкоманде. test -xпроверяет, является ли этот путь исполняемым для вас.
Обратите внимание, что, хотя вы можете выполнить команду, команда все равно может завершиться ошибкой, поскольку у нее недостаточно прав для выполнения задачи. Это распространенный случай в системах Unix-типа, которые вместо ограничения доступа для выполнения команды вместо этого ограничивают доступ к операциям, которые программы могут фактически выполнять.
alias shutdown="shutdown now"?
$(which shutdown)или $(shopt -u expand_aliases && command -v shutdown). Эта проблема появляется только в интерактивном режиме.
Ну, иногда это может быть немного сложно ...
Прежде всего, посмотрите на разрешения с 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. Опять же, нет общего способа узнать это без ручного осмотра или выдачи команды и наблюдения за результатами.
sudo) и выяснить. Команды текстового режима могут понадобитьсяsudoи графические команды могут понадобитьсяgksudo. Вы также можете проверить, где установлена командаwhich command. Если в/sbinили/usr/sbin- вы можете ожидать, что команда нуждаетсяsudoилиgksudo.