Получение прав администратора. Утилиты sudo, visudo и sudoedit

Автор: Алексей Федорчук
Мир Linux. Наброски к книге

Команда sudo  — это ещё один способ ущемления прав пользователя при доступе к аккаунту администратора. Он принят по умолчанию во всех дистрибутивах семейства Ubuntu, может быть задействован при инсталляции в Debian’е (хотя и по заказу) или подключён в любом другом дистрибутиве Linux.

Для убунтийца знание этой команды, ввиду умолчального отсутствия суперпользовательского пароля — практически необходимость: любое действие по установке программ или настройке чего бы то ни было, делается в дистрибутивах этого семейства через sudo. Однако она не повредит и пользователям более иных дистрибутивов, так как делает всякие настроечные и установочные мероприятия проще и безопасней.

Итак, sudo — это программа для получения прав суперпользователя (или любого иного пользователя), подобная su. Основных отличий от последней — два:

1. во-первых, sudo по умолчанию требует указания пароля того пользователя, который получает права другого, а не пароля того, чьи права приобретаются; правда, это может быть изменено;
2. Во-вторых, действие sudo распространяется по умолчанию только на одну команду — ту, которая указывается в качестве ее аргумента; хотя и такое поведение можно изменить с помощью соответствующих опций, о чём будет сказано позднее.

Этим достигается две цели: а) возможность выполнения пользователем административных действий без сообщения ему суперпользовательского пароля, и б) снижение риска повредить систему вследствие забывчивости. Да, есть еще и третья, дополнительная возможность, предоставляемая sudo — протоколирование действий, позволяющее определить, в результате чего система рухнула.

В элементарном виде применение команды sudo — элементарно же просто: требуется лишь указать в качестве ее аргумента имя команды, требующей исполнения, со всеми необходимыми последней опциями и аргументами. После этого запрашивается пароль запустившего её пользователя — и команда исполняется. Например, команда

$ sudo fdisk -l /dev/sda

данная от лица обычного пользователя, выведет информацию об указанном дисковом устройстве точно так же, как и данная root’ом.

Таким образом, утилита sudo в самом простом случае действует аналогично команде su -c [command], но более удобным образом. Во-первых, её команда-аргумент не нуждается ни в каком экранировании. Во-вторых, в должным образом настроенной оболочке bash в отношении команд-аргументов и путей — аргументов последних, будет действовать автодополнение по нажатию клавиши Tab. Уже одно это определяет предпочтительность sudo супротив su. А как добиться от bash столь образцового поведения — мы рассмотрим в главе о командных оболочках.

Кстати, если от лица суперпользователя нужно выполнить подряд несколько команд, делать это следует быстро — введенный первый раз пароль по умолчанию “действует” в течении 5 минут. То есть в течении этого времени в ответ на команду sudo пароль повторно запрашиваться не будет.

Период действия пароля для команды sudo можно увеличить, уменьшить или вообще ликвидировать, чтобы аутентификация запрашивался всегда. Это достигается редактированием конфигурационного файла утилиты, к чему мы вернёмся чуть позже.

Аналогичным образом пользователь может отредактировать общесистемный конфигурационный файл, например:

$ sudo nano -w /etc/fstab

Впрочем, для редактирования общесистемных конфигов предназначена специальная команда sudoedit (или просто sudo с опцией -e). Она не требует указания имени вызываемого для этой цели редактора: в качестве такового используется значение переменной EDITOR из окружения того пользователя, который ее вызвал. Если эта переменная не определена — а это обычно делается в профильных файлах регистрационной оболочки пользователя, — для редактирования вызывается редактор Vim (в своей упрощенной ипостаси, эмулирующей классический vi).

В Ubuntu и Kubuntu в качестве общесистемного редактора по умолчанию целесообразно использовать nano: он достаточно прост в освоении и использовании начинающим пользователем, а возможностей для редактирования пары-тройки конфигов у него вполне хватит.Убедиться в этом можно здесь.

Как это ни парадоксально, команда sudo не исключает запуска администраторского сеанса внутри обычного пользовательского. Потому что с ее помощью можно запустить ту же команду su:

$ sudo su

И это — даже в Ubuntu’идах, где root-аккаунта как бы и нет; точнее, по умолчанию нет его пароля. Но использование sudo делает его ненужным даже для команды su. Но и задать пароль суперпользователя не запрещается — ведь для этого достаточно дать команду

$ sudo passwd

чтобы в дальнейшем использовать su обычным образом. И даже, при желании, авторизоваться root’ом при регистрации в системе.

Впрочем, и тут команда sudo предусматривает “идеологически правильный” метод, и даже не один. Это — опции -s и -i, пролонгирующие, хотя и несколько по разному, действие команды sudo на неопределённый срок, вплоть до завершения «вторичного сеанса» командой exit.

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

Опция же -i полностью воспроизводит root-окружение, запуская его командную оболочку как регистрационную (login shell). Разумеется, при этом и текущий каталог меняется на /root, а приглашение командной строки приобретает вид, описанный в соответствующей переменной профильного файла администраторского шелла (в bash — PS1).

На практике разница между обеими формами обретения перманентных прав администратора не велика, особенно в bash. Но в zsh соответствующими настройками профильных файлов при желании можно добиться существенно разного окружения в каждом из этих случаев. Правда, насколько это нужно пользователю — большой вопрос. А вот то, что при использовании опций -H нахождение в перманентно административном режиме никак внешне не впроявляется, чревато ошибками. И делает в большинстве случаев применение опции -i предпочтительным.

К слову сказать, возможности sudo не ограничиваются запуском команд от лица администратора: задав опцию -u username, их можно выполнить и от лица того пользователя, чей логин задан в качестве её значения. Это может быть полезным при просмотре или копировании dot-файлов и dot-каталогов другого пользователя, часто открытых для чтения и изменения только их хозяину.

К слову сказать, команду sudo можно запустить так, чтобы она запрашивала пароль пользователя, от имени которого будет выполняться команда (например, администратора), а не того, кто требует его полномочий. Для этого существует опция -targetpw. А чтобы сделать требование root’ового пароля постоянным, достаточно определить, например, псевдоним типа

alias sudo -targetpw

Требование ввода root’ового пароля при запуске sudo — поведение её по умолчанию в некоторых дистрибутивах, например, как говорят, в Suse.

Команда sudo имеет еще немало опций — выше я привёл только те, которые мне приходилось использовать. Остальные легко посмотреть в man sudo. Из не перечисленных упомяну ещё опцию -b, предписывающую запускать «подсудную» команду в фоновом режиме. Она может быть полезна при выполнении долговременных действий, например, при копировании образов USB на флэшку командой dd.

Как мы только что увидели, команда sudo даёт пользователю практически неограниченные полномочия для любых как общесистемных действий, так и для манипуляции чужими пользовательскими данными. В связи с этим зададимся вопросами:

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

Если говорить о семействе Ubuntu, в котором механизм этот был впервые задействован «из коробки» —  то «из коробки» же ответ на первый вопрос будет отрицательным, на второй — положительным. А вообще это зависит от настроек программы sudo, которые описываются в файле /etc/sudoers. И в нем можно задать правила, допускающие к исполнению определенных команд только отдельных пользователей. В обобщенном виде это выглядит так:

username        host = command

Здесь, как нетрудно догадаться, username — имя пользователя, для которого устанавливается данное правило, host — имя машины, с которой он может к этому правилу прибегнуть, command — конкретная команда, использование которой разрешается данному пользователю с данной машины. Команда должна быть дана с указанием полного абсолютного пути (то есть /sbin/fdisk, а не fdisk). Поле описания команд может включать несколько значений, разделенных запятыми, например:

username        ALL = /sbin/fdisk,/bin/mount

В Ubuntu’идах по умолчанию правила доступа пользователей к административным привилегиям описываются так:

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin  ALL=(ALL) ALL

То есть пользователь root, как ему и положено, может исполнять любые команды с любых хостов. А вот получить права его могут только пользователи, входящие в группу admin (аналог группы wheel, о которой говорилось в предыдущем подразделе). Пользователь, создаваемый в ходе обычной установки, автоматически становится членом этой группы — и потому все административные права ему доступны без всяких дальнейших настроек. Однако прочие пользователи, чьи аккаунты будут созданы в последствие, этой привилегии лишены. Если, конечно, они не были специально включены в группу admin .

В более иных дистрибутивах, не использующих  sudo «из коробки», потребуется редактирование её конфигурационного файла — того самого /etc/sudoers, о котором упоминалось выше.

Файл /etc/sudoers — обычный текстовый, и, соответственно, его можно редактировать в любом текстовом редакторе (или, скажем, средствами ed или sed). Однако при этом существует определенный риск что-нибудь напортачить (за счет обычных опечаток), вплоть до того, что полностью закрыть самому себе доступ к привилегиям суперпользователя. Конечно, ситуации эти поправимы — например, через перезагрузку в однопользовательском режиме. Однако, лучше в них не попадать. И потому более надежным средством модификации /etc/sudoers будет использование специально предназначенной для того утилиты — visudo.

Утилита visudo не делает ничего сверхъестественного — она просто открывает /etc/sudoers в текстовом редакторе, описываемом переменной EDITOR суперпользователя (если таковая не определена, им будет опять же классический vi — отсюда и название) и позволяет его отредактировать обычным образом, после чего выйти из редактора с сохранением результатов штатными его средствами. Однако перед этим результат редактирования проверяется на корректность. И если обнаруживается нарушение синтаксиса, принятого для /etc/sudoers, выдается соответствующее предупреждение. После которого можно вернуться к редактированию, отказаться от сделанных изменений или все-таки принять их (разумеется, под личную ответственность).

Утилита visudo не гарантирует стопроцентного успеха редактирования. Так как проверяет только соответствие синтаксиса, но не “правильность самих правил”. То есть если ошибка будет допущена в указании пути к нужной для данного правила команде — эта команда через sudo не сработает.

Впрочем, на деле это выглядит обычно гораздо проще  и совсем не страшно. Так, в Fedora 11 мне в образцово-показательном конфиге /etc/sudoers пришлось лишь раскомментирвоать строку

%wheel  ALL=(ALL)	ALL

чтобы дать пользователю из указанной группы (а себя я туда включил заблаговременно, как было описано в предыдущем подразделе) все права, коими наделён администратор. Заодно можно было бы предоставить себе по блату и возможность использовать sudo без пароля. Для этого потребовалось бы снять комментарий со строки

# %wheel        ALL=(ALL)       NOPASSWD: ALL

Но я ограничился лишь тем, что сделал действие пароля более долгоиграющим, вписав (изначально отсутствующую строку

Defaults    timestamp_timeout=10

где значение таймаута указано в минутах. Кстати, если изменить его на ноль —

Defaults    timestamp_timeout=0

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

Можно, напротив, отключить тайаут на действие sudo, ввдея для него отрицательное  значение:

Defaults    timestamp_timeout=-1

В этом случае пароль будет запрошен только  при первом вызове этой команы.

Более пристальное вглядывание в файл /etc/sudoers легко подскажет возможности дать определённым пользователям или группам только ограниченный набор прав. Впрочем, тут уже начинаются тонкости всамделишнего администрирования. Я же просто лишил своего двойника-экспериментатора доступа к любым административным действиям, дабы пресечь все его поползновения на этом поприще. Впрочем, даже это не всегда позволяет мне с ним справляться — подобно тому, как Тимур Шаов не в силах совладать со своим лирическим героем.

[Содержание]