Иногда, просто необходимо запустить команду от другого пользователя. И существует несколько способов, как это можно сделать. Я расскажу о них в своей статья «Запустить команду от другого пользователя в Unix/Linux».
Запустить команду от другого пользователя в Unix/Linux — способ 1
И так, можно использовать утилиту SUDO. Рассмотрим пример:
$ sudo -H -u Your_another_user -c "ping сайт"
Пояснения:
- -H YOUR_HOME: Задает HOME (Переменное окружение для хома конкретного юзера) и по умолчанию — это root.
- -u YOUR_USER: Задаем пользователя от которого будет выполнена команда.
- -c YOUR_COMMAND: Служит опцией для ввода команды.
Как-то так.
Запустить команду от другого пользователя в Unix/Linux — способ 2
Можно использовать утилиту SU. И сейчас приведу несколько примеров.
Логин в root юзера
Чтобы получить рута, выполните:
$ su - root
Запустить команду как root юзер
Вот пример команды:
# su - root -c "YOUR_COMMAND_HERE"
Su - -c "YOUR_COMMAND_HERE arg1"
Выполнить команду от другого пользователя с помощью su
И так, вот пример:
# su -c "/opt/solr/bin/solr create -c test_solr_core -n solrconfig.xml" -s /bin/sh solr Created new core "test_solr_core"
Рассмотрим другой пример:
$ su another_user -c "ping сайт"
$ su - YOUR_USER -c "YOUR_COMMAND_HERE"
- — — Будет имитировать логин указанного пользователя.
- -c — Служит для указания команды для выполнения (для указанного юзверя).
Как-то так.
Запустить команду от другого пользователя в Unix/Linux — способ 3
И так, можно использовать утилиту runuser. Команда runuser запускает оболочку с заменяющими идентификаторами пользователей и групп. Эта команда полезна только когда вы залогинены как пользователь root. Синтаксис выглядит следующим образом:
# runuser -l YOUR_USER -c "YOUR_COMMAND_HERE"
Как пример, я покажу следующую строку:
# runuser -l nginx -c "service nginx start"
PS: Для использования команды runuser пароль не требуется, и он должен запускаться только пользователем root.
Основные опции:
- -l: Создаст оболочку для входа в систему, используя файл runuser-l PAM вместо стандартного.
- -g: Указывает на основную группу.
- -G: Указывает на дополнительную группу.
- -c: Собственно, служит для указания команды.
- –session-command=COMMAND: Передает одну команду в оболочку с опцией «-c» и не создает новый сеанс.
- -m: Не сбрасывайте переменные среды (ENV).
Вот и все, тема «Запустить команду от другого пользователя в Unix/Linux» завершена.
Если вы периодически используете команду sudo, я уверен, что вы заметили особенность ее работы, заключающуюся в том, что после успешного ввода пароля вы можете использовать sudo еще несколько раз вообще без ввода пароля. Но по истечении некоторого времени команда sudo снова начинает запрашивать ввод пароля.
Это поведение никак не связано с количеством исполненных посредством sudo команд, но связано с временем. Да, по умолчанию sudo не будет запрашивать ввод пароля в течение 15 минут после его успешной проверки. По истечении этих 15 минут sudo снова попросит ввести пароль.
Однако, при желании вы можете изменить описанное поведение. Для этого следует открыть файл конфигурации /etc/sudoers с помощью следующей команды:
Sudo visudo
После этого нужно перейти к строке
Defaults env_reset
и добавить в конец этой строки следующую переменную с новым значением (выделено жирным шрифтом):
Defaults env_reset,timestamp_timeout=[новое значение]
Поле "[новое значение]" должно быть заменено на количество минут, в течение которых должна существовать ваша сессия sudo. К примеру, я использовал значение 40.
Если вы хотите, чтобы запрос пароля осуществлялся при каждом использовании команды sudo, вы можете установить значение 0 данной переменной. А если вам нужно, чтобы сессия sudo длилась вечно, вы можете установить значение -1 данной переменной.
Пожалуйста учтите, что использование значения -1 рассматриваемой переменной настоятельно не рекомендуется.
Пароль sudo
Как вы могли заметить, в процессе ввода пароля не отображается никаких символов, даже привычных звездочек. Хотя это и не является большой проблемой, некоторым пользователям по различным причинам хочется видеть хотя бы звездочки.
К счастью, соответствующий режим ввода пароля достаточно просто активировать. Все, что вам нужно сделать - это изменить следующую строку в файле /etc/sudoers:
Defaults env_reset
на строку
Defaults env_reset,pwfeedback
Теперь при вводе пароля в процессе работы с утилитой sudo будут отображаться звездочки.
Некоторые важные параметры команды sudo
Помимо параметра -u (который мы обсуждали в начале данной статьи) существует несколько других важных параметров команды sudo, которые достойны упоминания. Мы обсудим некоторые из них в данном разделе.
Параметр -k
Предположим, что вы только что выполнили команду посредством sudo и ввели свой пароль. Как вы знаете, по умолчанию sudo не будет спрашивать пароль в течение следующих 15 минут. А теперь предположим, что вам понадобилось предоставить кому-либо доступ к своему терминалу без возможности использования sudo. Что можно предпринять в этом случае?
К счастью, существует параметр -k , позволяющий принудительно завершить сессию sudo. А вот что написано о данном параметре на странице руководства sudo:
-k, --reset-timestamp
При использовании без команды позволяет сбросить кэшированные параметры пользователя. Другими словами, при следующем вызове sudo будет запрашиваться пароль. Данный параметр не требует ввода пароля и был добавлен специально для того, чтобы у пользователей имелась возможность убрать информацию о правах доступа sudo из файла.logout .
При использовании вместе с командой или требующим пароля параметром может потребоваться ввод пароля, так как в результате использования данного параметра кэшированная информация о правах доступа sudo игнорируется. В результате sudo снова предложит ввести пароль (в том случае, если это требуется политикой безопасности) и не будет обновлять кэшированную информацию о правах доступа.
Параметр -s
Может случиться так, что в процессе работы вам потребуется выполнить множество команд, требующих привилегий пользователя root, и вам не захочется вводить префикс sudo перед каждой из них. Также вам не захочется настраивать длительность сессии sudo путем редактирования файла конфигурации /etc/sudoers .
В этом случае вам может пригодиться параметр -s . Это описание данного параметра со страницы руководства sudo:
-s, --shell
Запустить командную оболочку, путь к бинарному файлу которой задан с помощью переменной окружения SHELL , если таковая существует, или командную оболочку, путь к бинарному файлу которой задан в параметрах учетной записи вызывающего пользователя. В случае использовании команды, она будет передана в эту командную оболочку для последующего исполнения посредством стандартного параметра -c . Если команды не задано, пользователю будет предоставлен доступ к запущенной интерактивной командной оболочке.
Итак, данный параметр выполняет следующие действия:
- Запускает новую командную оболочку, путь к бинарному файлу которой задан с помощью переменной окружения $SHELL . В том случае, если переменная окружения $SHELL имеет пустое значение, запускается командная оболочка, путь к бинарному файлу которой указан в строке с описанием параметров учетной записи текущего пользователя в файле /etc/passwd .
- Если вы передаете команду вместе с параметром -s (например, исполняя команду sudo -s whoami), то исполняется следующая команда: sudo /bin/bash -c whoami .
- Если вы не пытаетесь исполнить какую-либо свою команду (то есть, просто исполняете команду sudo -s), вы получаете доступ к интерактивной командной оболочке с привилегиями пользователя root.
Следует иметь в виду, что параметр -s предоставляет в ваше распоряжение командную оболочку с привилегиями пользователя root, но без окружения пользователя root - эта командная оболочка будет использовать ваш файл.bashrc . По сути, это означает, что, к примеру, при исполнении с помощью этой командной оболочки команды whoami будет выводиться ваше имя пользователя, а не root.
Параметр -i
Параметр -i похож на параметр -s , который мы только что обсуждали. Однако, между ними имеются некоторые отличия. Одно из ключевых отличий заключается в том, что параметр -i также предоставляет вам окружение пользователя root, поэтому ваш (пользовательский) файл.bashrc игнорируется. Это сравнимо с использованием учетной записи пользователя root без входа в систему под именем пользователя root. Кроме того, вам не придется вводить пароль пользователя root.
Важное замечание: помните о том, что существует также команда su , которая позволяет работать от лица других пользователей (по умолчанию вы становитесь пользователем root). Данная команда требует ввода пароля пользователя root. Для того, чтобы избежать необходимости ввода пароля этого пользователя, вы можете также использовать префикс sudo (то есть, команду sudo su); в этом случае вам придется ввести ваш пароль. Однако, команды su и sudo su имеют некоторые отличия; для того, чтобы разобраться с ними, а также ознакомиться со сравнением данных команд с командой sudo -i достаточно обратиться к обсуждению, доступному по данной ссылке .
Заключение
Я надеюсь, что вы хотя бы в общих чертах поняли принцип работы команды sudo, а также методику изменения ее стандартного поведения. Самостоятельно испытайте описанные модификации файла /etc/sudoers и ознакомьтесь с обсуждением (ссылка на которое приведена в предыдущем параграфе), если хотите узнать об этой команде немного больше.
Немного о самом sudo, из wikipedia. sudo (англ. superuser do , дословно «выполнить от имени суперпользователя ») - это программа, разработанная в помощь системному администратору и позволяющая делегировать те или иные привилегированные ресурсы пользователям с ведением протокола работы. Основная идея - дать пользователям как можно меньше прав, но при этом ровно столько, сколько необходимо для решения поставленных задач.
Команда sudo предоставляет возможность пользователям выполнять команды от имени root, либо других пользователей. Правила, используемые sudo для принятия решения о предоставлении доступа, находятся в файле /etc/sudoers; язык их написания и примеры использования подробно изложены в sudoers(5).
Для редактирования файла /etc/sudoers следует использовать программу visudo, которая проверяет синтаксис и тем самым позволяет избежать ошибок в правилах.
В большинстве случаев грамотная настройка sudo делает работу от имени суперпользователя ненужной.
По умолчанию root аккаунт в Ubuntu отключен и пароля у root просто нет. Все административные задачи выполняются через sudo. По умолчанию право на выполнение sudo предоставлено первому пользователю, созданному при инсталляции. Все остальные по умолчанию – обычные пользователи.
Sudo - очень гибкий инструмент, позволяющий настроить права на выполнения административных действий для каждого пользователя отдельно. Например одному разрешить перезагружать какой-либо сервер, а другому дать возможность менять права доступа к файлам и папкам. Откройте файл /etc/sudoers. Это можно сделать либо отдав команду на открытие файла в вашем любимом текстовом редакторе, например так:
# nano /etc/sudoers
либо при помощи утилиты visudo:
# visudo
Последний способ откроет файл /etc/sudoers в редакторе пользователя по умолчанию, или если таковой не задан, то в редакторе vi. Преимущество данного способа в том, что при сохранении файл будет проверен на соответствие синтаксису.
Простейшая конфигурация выглядит так:
Defaults env_reset
# User privilege specification
root ALL=(ALL) ALL
user ALL=(ALL) ALL
Такая конфигурация дает пользователю user все права пользователя root при выполнении команды sudo. Defaults env_reset
полностью запрещает все пользовательские переменные при исполнении команд от имени root. Это хорошо с точки зрения безопасности, однако иногда вызывает проблемы. Можно разрешить использование личных переменных какой-либо группе или отдельному пользователю, добавив подобную этой строку:
Defaults:%admin !env_reset
которая будет сохранять переменные окружения для всех пользователей группы admin, или:
Defaults:user env_keep=TZ
которая сохранит переменную TZ для пользователя user.
Если сервер администрируется группой людей, то имеет смысл поступить таким образом:
%admin ALL=(ALL) ALL
Как можно догадаться, эта запись дает доступ к root-привилегиям всем членам группы admin.
Можно настроить для каждого конкретного пользователя доступ только к конкретным командам. Например:
user ALL = /bin/mount, /bin/kill
даст пользователю user права на выполнение команд mount и kill с любой машины, а:
user2 mydebiancomp = /sbin/modprobe
даст пользователю user2 права на выполнение modprobe с машины mydebiancomp. Я думаю, что синтаксис понятен:
ползователь хост = команда
где команда прописывается с полным путем. Для группы все аналогично, только добавляется знак “%”.
III.Продвинутые настройки sudo.
Очень удобно при настройке sudo создать группу алиасов. Чтобы не вбивать постоянно повторяющиеся команды, пользователей и хосты, мы можем собрать их в группы и устанавливать правила для каждой группы алиасов. Например так:
Cmnd_Alias command_alias = command1, command2, … // алиасы команд
Host_Alias host_alias = hostname1, hostname2, … // алиасы хостов
User_Alias user_alias = user1, user2, … // алиасы пользователей
Исполнение команды от имени другого пользователя тоже возможно. Например при такой записи:
user ALL = (user2, user3) /usr/bin/ark
пользователь user может выполнить команду ark от имени user2 или user3, при помощи ключа u, например так:
$ sudo -u user2 ark
По умолчанию sudo запоминает пароли на 5 минут. Если вы этого не хотите, то для каждого пользователя, группы или алиаса можете установить отдельное правило, например при:
Defaults:user timestamp_timeout=0
пароль полдьзователя user не будет запоминаться вообще, а при:
Defaults:user timestamp_timeout=-1
будет запоминаться на все время аптайма.
Sudo без паролей также возможно. Для этого существует подобная конструкция:
user myubuntucomp = NOPASSWD: /bin/kill
которая даст возможность пользователю user с хоста myubuntucomp использовать kill без запроса пароля. Вставьте свои значения, например ALL вместо имени хоста и команды, чтобы пользователь user мог вообще никогда не вводить пароль для выполнения команд от имени root с любого хоста, однако помните, что это делает систему очень уязвимой.
Постовой
Блоги, блоги, блоги. Максим Fuckin знает в этом толк.
Интерактивная карта города Оренбурга . Выполнена по технологии Google maps с применением собственных разработок. Ресурс молодой, но уже достаточно интересный и полезный.
С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации Ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano , а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root"ового шелла предлагается писать sudo su - . Попробую объяснить, почему такое положение вещей кажется мне неправильным.
Исторически единственным универсальным способом выполнить команду от имени другого пользователя в Unix была программа su. Запущенная без параметров, она запрашивала пароль суперпользователя и в случае успеха просто подменяла текущее имя пользователя на root, оставляя почти все переменные окружения от старого пользователя (кроме PATH, USER и еще пары-тройки, см. man su от своего дистрибутива). Более корректно было запускать ее как su - - в таком случае оболочка получала также и правильный environment. С параметром -c можно было выполнить команду: su -c "vim /etc/fstab" .
При этом доверенным пользователям приходилось помнить пароль root"а и у всех пользователей, перечисленных в группе «wheel» (т.е. в группе, члены которой могли выполнить команду su и стать суперпользователем), был одинаковый неограниченный доступ ко всей системе, что являлось серьёзной проблемой безопасности.
Затем появилась команда sudo, и это был прорыв. Теперь администратор мог указывать список разрешенных команд для каждого пользователя (или группы пользователей), файлы, доступные для редактирования, специальные переменные окружения и многое другое (все это великолепие управляется из /etc/sudoers , см. man sudoers от своего дистрибутива). При запуске sudo спрашивает у пользователя его собственный пароль, а не пароль root. Полноценный шелл можно получить с помощью " sudo -i "
Стоит особо упомянуть о специальной команде sudoedit , безопасно запускающей редактор, указанный в переменной окружения $EDITOR . При более традиционной схеме редактирование файлов производилось примерно так:
sudo vi /etc/fstab
Запускаемый таким образом vi наследовал оболочку с неограниченными правами и через:! пользователь мог запускать любую команду (если, конечно, админ не позаботился об этом заранее) и открыть любой файл.
Sudoedit проверяет, можно ли этому пользователю изменять данный файл, затем копирует указанный файл во временный каталог, открывает его в редакторе (который наследует права пользователя, а не root"а), а после редактирования, если файл был изменён, с особыми предосторожностями копирует его обратно.
В Debian-based дистрибутивах пользователь root не имеет пароля, вместо этого все административные действия должны производиться через sudo или его графический аналог gksudo . Являясь полной заменой su , sudo должна бы быть единственной командой переключения между пользователями, однако, как было сказано вначале, в настоящий момент это не так и все зачем-то изобретают дикие последовательности из sudo, su, vi и черточек.
Поэтому предлагаю всем раз и навсегда запомнить:
После первой публикации этой заметки мне было задано несколько вопросов. Из ответов получилось сделать мини-FAQ.
Q: как с помощью sudo сделать su -c "echo 1 > /etc/privileged_file" ? sudo echo 1 /etc/privileged_file ругается на «permission denied»
A: Это происходит потому, что только команда echo выполняется в повышенными правами, а результат перенаправляется в файл уже с правами обычного пользователя. Чтобы добавить что-нибудь в privileged_file, нужно выполнить такую команду:
$ echo 1| sudo tee -a privileged_file >/dev/null
Или же временно стать рутом:
$ sudo -i
# echo 1 > privileged_file
# exit
$
Q: sudo -i длиннее, чем su - , а разницы между ними вроде как и никакой, зачем печатать больше?
A: У sudo есть несколько преимуществ, ради которых стоит потрудиться набрать несколько лишних символов:
- по умолчанию sudo записывает всю пользовательскую активность в syslog-канал authpriv (как правило, результат кладется в файл /var/log/auth.log), а в su подобную фичу надо включать с помошью задания специального параметра в файле настроек, различающемся от дистрибутива к дистрибутиву (SULOG_FILE в /etc/login.defs в Ubuntu Linux, /etc/login.conf и /etc/pam.d/su в FreeBSD и т.д.)
- в случае с su администратор системы не может ограничить команды, выполняемые пользователями, а в sudo - может
- если пользователь должен быть лишен права администрирования, в случае с su после удаления его из группы wheel он должен забыть пароль root"а; если используется sudo, достаточно вынести его из соответствующей группы (например, wheel или admin) и/или файла sudoers, если он был дополнительно настроен.
A: отвечу вопросом на вопрос: если есть правильный sudo, зачем использовать устаревший su?
Каждый владелец серверной машины знает, что не стоит доверять полный доступ (root) всем подряд.
Последствия некоторых таковых моментов мы знаем. И, для упрощения жизни, в Unix-ядро
внедрена команда sudo
.
Инструмент который дает права пользователям выполнять команды с привилегиями суперпользователя. Например разрешает младшим администраторам использовать те или иные команды, для выполнения задач в рамках компетенции.
Суперпользователь root - администраторский аккаунт в Unix (а так-же Unix-подобных OC) с идентификатором 0, которому позволено выполнить все команды без исключения.
Устанавливается из репозиториев при помощи пакетного менеджера: apt-get install sudo или yum install sudo .
Конфигурация sudo
разрешает указать пользователя, группу пользователей, хосты и запрос или отсутствие запроса пароля при выполнении.
Например выполнение команды от имени другого пользователя.
Запустить Midnight Commander с правами суперпользователя
Открыть в текстовом редакторе nano файл nginx.config от пользователя Anton .
Sudo -u anton nano /etc/nginx/nginx.config
Файл конфигурации
sudoers
расположен в директории /etc/
.
Для редактирования файла конфигурации используется команда visudo
.
Изменять файл /etc/sudoers текстовым редактором не стоит, т.к. при сохранение синтаксис не проверяется, как в случае с visudo .
Шаблон прав пользователей в конфигурационном файле /etc/sudoers
Пользователь/%группа ALL/название_хоста/+группа_машин = ALL/перечисление_команд_через_запятую (дополнительные параметры):
Разрешает пользователю anton выполнять все команды на всех хостах (с запросом пароля)
Anton ALL=(ALL) ALL
Разрешает группе admins выполнять все команды на машине Alpha (без ввода пароль)
%admins Alpha = ALL NOPASSWD: ALL
По умолчанию при выполнение команд через sudo требуется авторизоваться по паролю. Отключить авторизацию можно с помощью параметра NOPASSWD )
Предусмотрена в sudo и объединением групп команд в псевдонимы.
Объединение команд для работы с сетью в одну сущность NETWORKING
Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool
Использовать их можно например для ограничение прав пользователя или группы на выполнение команд затрагивающих сервис.
Разрешить использовать все команды пользователю Egor и группе devops, кроме тех, что в группе NETWORKING
Egor ALL = ALL, !NETWORKING %devops ALL = ALL, !NETWORKING
Мы рассмотрели часть функционала sudo для детального ознакомления используйте man pages из поставки вашего дистрибутива.