С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной
документации 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 и
черточек.
Поэтому предлагаю всем раз и навсегда запомнить:
что хотим сделать? | правильно | неправильно |
выполнить команду от имени root | sudo command | su -c «command» |
отредактировать файл от имени root |
sudoedit file |
su vim file sudo vim file |
получить оболочку root | sudo -i |
su - sudo su - |
Мини-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 есть несколько преимуществ, ради которых стоит потрудиться набрать несколько лишних символов:
SULOG_FILE
в /etc/login.defs
в Ubuntu Linux, /etc/login.conf
и /etc/pam.d/su
в FreeBSD и
т.д.)
Q: я единственный пользователь своей системы и привык к su, зачем мне
sudo?
A: отвечу вопросом на вопрос: если есть правильный sudo, зачем использовать устаревший
su?