Алексей Федорчук
Команда sudo
активно применяется убунтийцами… хотя, вопреки легендам, бытующим среди убунтофилов и убунтофобов, не только ими. А также всякими злобными админами, не желающими делиться с юзерами своим админским паролем — вот бывают же такие злодеи во всех Linux’ах, даже в таком его дистрибутиве, как FreeBSD. Однако я отвлёкся.
В большинстве случаев команда sudo
применяется при выполнении разовых операций, требующих полномочий администратора — например, при установке пакетов или редактировании общесистемных конфигурационных файлов. Однако бывают ситуации, когда права администратора требуются на протяжении некоторого времени, превышающего срок «выдыхания» введённого пароля (по умолчанию, если память не изменяет, 3 минуты).
Как обычно, задача эта решается разными методами. Первый — просто изменить срок действия команды sudo
, дописав в файл /etc/sudoers
строку
Defaults timestamp_timeout=30
Здесь значение опции timestamp_timeout
— время «выдыхания» в минутах. А написав Defaults:username
, это время можно задать только для конкретного пользователя. К слову сказать, если для временного параметра указать значение 0, то пароль будет запрашиваться при каждом обращении к команде sudo
.
Однако некоторые действия (например, настройка поддержки ZFS), требуют иногда даже размышлений, на которые получаса может и не хватить. И тогда есть смысл получить права администратора на неопределённое время, вплоть до особого распоряжения.
И здесь опять-таки возможны варианты. Первый — команда sudo -i
без указания аргументов. Это полный аналог команды su -
(или просто авторизации root’ом в консоли, если доступ к его аккаунту в данной системе по умолчанию предусмотрен). В этом случае время суперпользовательских полномочий не ограничено, и завершается только после явной команды exit
. А до того будет иметь место следующее:
- регистрационная оболочка пользователя сменится на login shell администратора;
- будут считаны все настройки из её профильных конфигов в каталоге
/root
(например,/root/.bashrc
); - текущий каталог изменится с
path2что_было
на/root
.
Кстати говоря, команда sudo -i
может использоваться и для выполнения единичного действия, требующего полной смены переменных оболочки и окружения на суперпользовательские (например, его значений для переменной $PATH). Очевидно, что это делается примерно таким образом:
$ sudo -i имя_команды [опции] [аргументы]
Столь же очевидно, что в этом случае явного сигнала об окончании полномочий администратора не требуется. Хотя для гарантии, что они действительно прекратились, можно дать команду
$ sudo -K
Впрочем, случая проверить действенность этой команды у меня случая не было.
Как я только что говорил, команда sudo -i
приводит к смене текущего каталога и регистрационного шелла, что не всегда желательно. Особенно если login shell пользователя и администратора разные. Например, у меня роль первого выполняет Zsh, настроенный подходящим для меня образом, и в среде Bash я всё время путаюсь, да и умолчально раскрашенный Штирлиц шелл меня раздражает. А менять login shell для root’а по некоторым причинам не хочется.
И потому я для перманентного доступа к правам администратора я обычно использую команду sudo -s
: в этом случае сохраняется и текущий каталог, и командная оболочка пользователя. Правда, конфиг её перечитывается из каталога /root
. Но если скопировать в него файл ~/.zshrc
, то в сеансе sudo
будет полностью воссоздано привычное окружение пользователя.
Может возникнуть вопрос, а как быть с теми переменными окружения, которые у пользователя и администратора обычно различаются (на практике тут важнее всего различие в значениях переменной $PATH
). Опять-таки, по разному. Можно просто отредактировать надлежащим образом соответствующий профильный файл (например, /root/.zshrc
). А можно обратиться к файлу /etc/sudoers
и либо отредактировать в нём строку
Defaults secure_path=""
либо дописать её. И в качестве значений перечислить в ней все каталоги, наряду с пользовательскими, доступ к которым необходим root’у. Подчёркиваю — все, то есть и /bin
, и /sbin
, и так далее: она не добавляет значения в пользовательский $PATH
, а подменяет его.
И последнее: редактировать /etc/sudoers
лучше не напрямую, а командой
$ sudo visudo
Она вызовет для редактирования файла /etc/sudoers
текстовый редактор, указанный как значение переменной $EDITOR
пользовательского конфига (а вовсе не обязательно vi
) и перед его сохранением проверит внесённые изменения на соответствие синтаксису. Что избавит от грубых ошибок, которые могут воспрепятствовать доступу к sudo
вообще.
При таком названии статьи не хватает варианта полного отключения вызова пароля для sudo для конкретного пользователя через коррекцию файла /etc/sudoers
Не нужно полное отключение пароля, а то юзеры плохому научатся. Хотя вариант для отключения пароля для конкретных команд вполне пойдет.
вопрос только, для каких команд это хорошо, а для каких плохо
2 Fangel
А юзера то как это ограничит ? пароль то остается ему доступен. Захочет, то снесет систему и через подключенный пароль, и через отключенный.
просто раз уж статья разбирает варианты sudo, то правильней включать в обзор и вариант полного отключения пароля.
2 Anton Serov Вообще-то рассматриваются варианты, которые я сам считаю правильными, применяю и могу посоветовать другим.
Вариант с отключённым паролем я никому не посоветую. Кто считает его правильным — пусть сам с ним разбирается.
> даже в таком его дистрибутиве, как FreeBSD
sudo в данной ОС в штатную поставку не входит, su вполне хватает.
Тем не менее, впервые про sudo я услышал лет 15 назад от Free’шного админа. И для него она была совсем не лишней.