Что такое sudo в линукс. Все, что нужно для понимания sudo vs su в Ubuntu Linux. Настройка sudo и прав доступа на выполнение различных команд

Оригинал: The Beginner’s Guide to Shell Scripting: The Basics
Автор: Yatri Trivedi
Дата публикации: 29 сентября 2015 г.
Перевод: А.Панин
Дата перевода: 4 октября 2016 г.

Тема разработки сценариев командной оболочки постоянно поднимается на форумах, посвященных операционной системе Linux, но многие пользователи все же мало знакомы с ней. Изучение этого простого и мощного метода программирования поможет сохранить ваше время, лучше узнать особенности утилит с интерфейсом командной строки и оптимизировать рутинные операции управления файлами.

Подробнее о процессе разработки сценариев командной оболочки

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

Те из вас, кто активно работал с Windows до перехода на Linux, наверняка помнят о batch-файлах. Это небольшие текстовые файлы, в которые могут помещаться последовательности команд для последующего исполнения силами Windows. Это разумный и удобный механизм для выполнения различных операций, таких, как запуск игр в школьном компьютерном классе в том случае, если нет возможности создания директорий или ярлыков. Хотя batch-файлы и могут оказаться полезными в Windows, они являются всего лишь дешевой имитацией сценариев командной оболочки.

Сценарии командной оболочки позволяют создавать цепочки команд и исполнять их таким же образом, как и в случае batch-файлов. При этом они предоставляют в ваше распоряжение гораздо большее количество полезных функций, позволяющих выполнять такие действия, как подстановка команд. К примеру, вы можете выполнить такую команду, как date и использовать ее вывод в качестве части схемы именования файлов. Таким образом вы можете автоматизировать процесс создания резервных копий данных с добавлением к имени каждого скопированного файла текущей даты. При этом содержимое сценариев командной оболочки не должно ограничиваться вызовами команд. По своей сути эти сценарии являются полноценными программами. По этой причине вы сможете использовать в процессе разработки сценариев такие классические синтаксические конструкции языков программирования, как циклы for , условные инструкции if/then/else и так далее, непосредственно на уровне интерфейса командной строки системы. И вам не придется изучать другой язык программирования, ведь вы уже используете известный вам интерфейс: командную строку.

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

Перед тем, как начать работу

Перед тем, как мы начнем рассматривать вопросы разработки сценариев командной оболочки в рамках серии статей, следует определиться с некоторыми аспектами. Мы будем использовать командную оболочку Bash, которая по умолчанию используется практически во всех дистрибутивах Linux. При этом она также доступна и для пользователей Mac OS, и для пользователей Windows благодаря существованию набора библиотек Cygwin. Благодаря такой универсальности, вы сможете создавать сценарии командной оболочки вне зависимости от используемой программной платформы. В дополнение следует упомянуть о том, что сценарии будут запускаться без модификации или после минимальной модификации на всех упомянутых программных платформах при условии наличия всех используемых в них утилит в системе.

В рамках сценариев командной оболочки могут использоваться утилиты, требующие привилегий "администратора" или "суперпользователя", поэтому стоит тщательно тестировать каждый сценарий перед его вводом в эксплуатацию. Также в процессе разработки сценариев нужно руководствоваться здравым смыслом, к примеру, проверяя наличие резервных копий файлов, которые обрабатываются с помощью них. Очень важно использовать корректные параметры команд, например, параметр -i команды rm , принудительно активирующий интерактивный режим. Это позволит избежать некоторых неприятных ошибок. По этой же причине следует тщательно изучать загружаемые из сети сценарии и на всякий случай создавать резервные копии персональных данных.

По своей сути сценарии командной оболочки являются обычными текстовыми файлами. Вы можете использовать любой текстовый редактор для их редактирования: gedit, emacs, vim, nano… И этот список можно продолжить. Следует просто убедиться в том, что выбранный текстовый редактор может сохранять код сценариев в обычных текстовых файлах, а не файлах со специальной разметкой или файлах, используемых одним из офисных пакетов. Так как мне нравится простота текстового редактора nano, я буду использовать его.

Имена и права доступа к файлам сценариев

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

Chmod +x ~/somecrazyfolder/script1

Эта команда позволит любому пользователю исполнять сценарий с заданным именем. Если вы хотите, чтобы данный сценарий могли исполнять лишь вы, вам придется использовать данную команду вместо приведенной выше:

Chmod u+x ~/somecrazyfolder/script1

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

Cd ~/somecrazyfolder ./script1

Для упрощения процесса разработки сценариев командной оболочки вы можете просто размещать все свои сценарии в директории bin , расположенной в вашей домашней директории:

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

Перед вводом имени сценария вы должны выполнить следующую команду для того, чтобы убедиться в отсутствии в системе программы с таким же именем:

Which [имя_сценария]

Многие начинающие разработчики сценариев командной оболочки создают файлы сценариев с такими именами, как "test" , после чего пытаются запустить их из эмулятора терминала и не получают какого-либо вывода. Это происходит по причине наличия конфликта между именем файла сценария и именем системной команды test , которая не выполняет каких-либо действий при отсутствии аргументов. Всегда проверяйте, не конфликтует ли имя вашего сценария с именем одной из существующих команд, ведь в этом случае вы можете потратить достаточно времени на решение проблемы, которую достаточно просто избежать!

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

Каждый сценарий должен начинаться со строки "#!/bin/bash"
Каждая новая строка сценария должна содержать новую команду
Строки комментариев должны начинаться с символа #
Команды для подстановки должны помещаться в круглые скобки ()

Хэш-банг

При разборе содержимого текстового файла основным идентификатором сценария является его первая строка:

#!/bin/bash

Если вы используете другую командную оболочку, вы можете подставить путь к ее исполняемому файлу в данную директиву. Строки комментариев всегда начинаются с символов решетки (#), но в случае наличия после первого символа решетки символа восклицательного знака (!) и пути к исполняемому файлу командной оболочки имеет место исключение из данного правила, позволяющее исполнить сценарий с помощью командной оболочки, путь к исполняемому файлу которой задан.

Новая строка = новая команда

Каждая новая строка сценария должна рассматриваться как новая команда или компонент более сложной синтаксической конструкции. Инструкции if/then/else , к примеру, могут занимать по нескольку строк, но каждый из их элементов все равно будет расположен на новой строке. Вы не должны переносить команды на новые строки, так как это приведет к сокращению первой строки и выводу сообщения об ошибке после попытки исполнения второй. Если ваш текстовый редактор самостоятельно выполняет эту операцию, вы на всякий случай должны отключить функцию автоматического переноса строк. В текстовом редакторе nano функция автоматического переноса строк отключается с помощью комбинации клавиш Alt+L .

Комментарии обычно начинаются с символа #

Если вы разместите символ # в начале строки, командная оболочка проигнорирует эту строку. Строка превратится в комментарий, с помощью которого вы можете напомнить себе о том, что выводит предыдущая команда или о том, что будет делать следующая. И снова следует отключить функцию автоматического переноса строк, а в случае необходимости переноса строки не стоит забывать о первом символе решетки. Использование подробных комментариев является отличной практикой, упрощающей модификацию ваших сценариев как вами, так и сторонними пользователями. Единственным исключением из данного правила является упомянутая выше конструкция хэш-банг, поэтому не стоит использовать символ восклицательного знака (!) сразу же после символа решетки (#) в комментариях.

Команды для подстановки помещаются в круглые скобки

Не так давно все подстановки команд осуществлялись с помощью символов обратного апострофа (` , расположен на клавиатуре на той же клавише, что и символ тильды ~). Мы пока не будем рассматривать данную тему, но ввиду того, что многие люди перечитывают статьи с вводной информацией, следует упомянуть о том, что вместо символов обратного апострофа следует использовать символы круглых скобок. Это стоит делать главным образом по той причине, что при вложении команд, то есть, размещении одних команд в рамках других команд, круглые скобки работают лучше.

Ваш первый сценарий

Давайте начнем с разработки простого сценария, позволяющего копировать файлы с добавлением даты к их именам. Назовем этот сценарий "datecp" . В первую очередь предлагаю убедиться в том, что имя сценария не конфликтует с именем какой-либо системной утилиты:

Как несложно заметить, команда which не выводит каких-либо данных, следовательно, ничто не мешает нам использовать это имя файла сценария.

Теперь давайте создадим пустой файл в директории ~/bin:

Пока мы не забыли, следует изменить установленные по умолчанию права доступа к только что созданному файлу сценария:

Теперь можно начинать работу над кодом сценария. Для этого следует открыть созданный пустой файл в выбранном текстовом редакторе. Как я уже говорил, мне нравится простота текстового редактора nano, поэтому я буду использовать именно его.

Nano ~/bin/datecp

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

Далее нужно объявить переменную. Если вы когда-либо изучали алгебру, вы наверняка знаете, что это такое. Переменная позволяет сохранять информацию и осуществлять определенные манипуляции с ней. Переменные могут "раскрываться" при упоминании в каком-либо другом месте сценария. То есть, вместо вывода их имен будет осуществляться вывод сохраненных в них значений. Впоследствии вы сможете сохранить в переменной новую информацию, причем в следующих операциях с данной переменной будет использоваться уже эта новая информация. Это очень удобная сущность для хранения тех или иных данных.

Какие же данные мы будем хранить в нашей переменной? Ну, давайте сохраним в ней дату и время! Для этого нам придется вызвать команду date .

Обратите внимание на приведенный ниже снимок окна терминала с выводом команды date:

Несложно заметить, что путем добавления различных параметров форматирования, имена которых начинаются с символа % , вы можете изменять формат вывода команды по своему усмотрению. Для ознакомления с дополнительной информацией вы можете ознакомиться со страницей руководства команды date .

Давайте используем последний вариант набора параметров форматирования команды date , а именно, "date +%m_%d_%y-%H.%M.%S" , в нашем сценарии.

Если мы сохраним этот сценарий прямо сейчас и выполним его, мы получим вполне ожидаемый вывод команды date:

Но давайте поступим немного по-другому. Я предлагаю сохранить вывод данной команды в переменной с заданным именем, таким, как date_formatted . Корректный синтаксис данной операции выглядит следующим образом:

Переменная=$(команда -параметры аргументы)

В нашем случае данная синтаксическая конструкция будет выглядеть следующим образом:

Date_formatted=$(date +%m_%d_%y-%H.%M.%S)

Именно это и называется подстановкой команд. Мы сообщаем bash, что при каждом упоминании переменной "date_formatted" следует выполнять команду, помещенную в круглые скобки. После этого при упоминании переменной "date_formatted" качестве вывода вместо ее имени будет использоваться вывод команды в круглых скобках.

А это пример сценария и его вывод:

Обратите внимание на наличие двух символов пробела в выводе. Эти символы находятся в рамах команды echo перед кавычками, а также перед именем переменной. Не используйте пробелы, если вы не хотите, чтобы они присутствовали в выводе. Также следует обратить внимание на то, что при отсутствии строки с командой "echo" сценарий не будет выводить каких-либо данных.

Давайте вернемся к нашему сценарию. Добавим в него команду копирования файла:

Cp -iv $1 $2.$date_formatted

В данном случае используется команда для копирования файла с параметрами -i и -v . Первый параметр позволяет вам подтвердить свои намерения перед перезаписью файла, а второй - вывести информацию о параметрах, переданных команде.

Далее вы можете обнаружить, что я добавил параметр $1 . При разработке сценариев знак доллара ($) со следующим за ним числовым значением соответствует аргументу сценария под номером, равным этому числовому значению. Например, в следующей команде:

Cp -iv Trogdor2.mp3 ringtone.mp3

первым аргументом является "Trogdor2.mp3" , а вторым - "ringtone.mp3" .

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

Это означает, что при запуске сценария нам придется передавать ему два аргумента для корректной работы. Первый аргумент, $1 , является именем копируемого файла, подставляемым в качестве первого аргумента команды "cp -iv" .

Второй аргумент, $2 , выступает в качестве имени целевого файла в рамках этой же команды. Но вы также можете обнаружить его важное отличие. Я добавил к нему символ точки и упоминание рассмотренной выше переменной "date_formatted" . Вам интересно, для чего предназначена такая конструкция?

А это вывод сценария после его запуска:

Очевидно, что имя целевого файла состоит из имени файла, переданного посредством второго аргумента сценария $2 , а также находящихся после него символа точки и вывода команды date ! Все логично, не так ли?

Теперь при выполнении команды datecp будет осуществляться запуск данного сценария, позволяющего осуществить копирование файла с автоматическим добавлением к имени целевого файла информации о текущих дате и времени. Это довольно удобно в том случае, если нужно осуществлять резервное копирование файлов!

Разработка сценариев командной оболочки просто необходима в том случае, если вы желаете заставить свою систему работать так, как вам хочется. Для этой цели вам не придется изучать какой-либо новый язык программирования. Попрактикуйтесь в создании своих собственных сценариев командной оболочки на основе системных команд и подумайте о том, для чего они смогут впоследствии использоваться.

Вы уже имеете опыт создания собственных сценариев командной оболочки? Вам есть что сказать начинающим пользователям? Поделитесь своим опытом в разделе комментариев! Мы рассмотрим другие аспекты процесса разработки сценариев командной оболочки в следующих статьях серии!

Прежде чем переходить к обсуждению того, как программа использует оболочку, давайте рассмотрим, как функционирует оболочка и какие оболочки есть в Linux-подобных системах. Командная оболочка - это программа, которая действует как интерфейс между вами и ОС Linux, позволяя вам вводить команды, которые должна выполнить операционная система. В этом смысле она похожа на командную строку в ОС Windows, но, как уже упоминалось, командные оболочки Linux гораздо мощнее. Например, ввод и вывод можно перенаправить с помощью символов < и > , передавать данные между двумя одновременно выполняющимися программами с помощью символа | , а перехватывать вывод подпроцесса с помощью конструкции $(...) . В ОС Linux вполне может сосуществовать несколько установленных командных оболочек, и разные пользователи могут выбрать ту, которая им больше нравится. На рис. 2.1 показано, как командная оболочка (на самом деле, две командные оболочки: bash и csh) и другие программы располагаются вокруг ядра Linux.

Рис. 2.1

Поскольку ОС Linux - модульная система, вы можете вставить и применять одну из множества различных стандартных командных оболочек, хотя большинство из них - потомки первоначальной оболочки Bourne. В Linux стандартная командная оболочка, всегда устанавливаемая как /bin/sh и входящая в комплект средств проекта GNU, называется bash (GNU Bourne-Again SHell). Именно ее мы будем применять, т. к. это отличная командная оболочка, всегда устанавливаемая в системах Linux, со свободно распространяемым программным кодом и переносимая почти на все варианты UNIX-систем. В данной главе используется оболочка bash версии 3, и в большинстве случаев применяются ее функциональные возможности, общие для всех командных оболочек, удовлетворяющих требованиям стандарта POSIX. Мы полагаем, что командная оболочка, установленная как /bin/sh и для вашей учетной записи, считается командной оболочкой по умолчанию. В большинстве дистрибутивов Linux программа /bin/sh, командная оболочка по умолчанию, - это ссылка на программу /bin/bash.

Вы можете определить используемую в вашей системе версию bash с помощью следующей команды:

$ /bin/bash --version
GNU bash, version 3.2.9(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

Примечание

Для перехода на другую командную оболочку, если в вашей системе по умолчанию установлена не bash, просто выполните программу нужной вам командной оболочки (т.е. /bin/bash) для запуска новой оболочки и смены приглашения в командной строке. Если вы используете ОС UNIX, и командная оболочка bash не установлена, вы можете бесплатно загрузить ее с Web-сайта www.gnu.org. Исходный код обладает высокой степенью переносимости, и велика вероятность, что он откомпилируется в вашей версии UNIX прямо в готовую к использованию программу.

Когда создаются учетные записи пользователей ОС Linux, вы можете задать командную оболочку, которой они будут пользоваться, в момент создания учетной записи пользователя или позже, откорректировав ее параметры. На рис. 2.2 показан выбор командной оболочки для пользователя дистрибутива Fedora.

Рис. 2.2

Существует много других командных оболочек, распространяемых свободно или на коммерческой основе. В табл. 2.1 предлагается краткая сводка некоторых самых распространенных командных оболочек.

Таблица 2.1

Название командной оболочки	Краткие исторические сведения
sh (Bourne)	Первоначальная оболочка в ранних версиях ОС UNIX
csh, tcsh, zsh	Командная оболочка C-shell (и ее производные), первоначально созданная Биллом Джойем (Bill Joy) для систем Berkeley UNIX. C-shell, возможно, третья по популярности командная оболочка после оболочек bash и Korn
ksh, pdksh	Командная оболочка Korn и ее безлицензионный родственник. Написанная Дэвидом Корном (David Korn) эта оболочка применяется по умолчанию во многих коммерческих версиях UNIX
bash	Основная командная оболочка ОС Linux из проекта GNU или Bourne Again SHell со свободно распространяемым программным кодом. Если в настоящий момент она не выполняется в вашей системе UNIX, вероятно, есть вариант оболочки, перенесенный на вашу систему. У bash много сходств с оболочкой Korn

За исключением оболочки C-shell и небольшого числа ее производных все перечисленные оболочки очень похожи и очень близки к оболочке, определенной в спецификациях Х/Оpen 4.2 и POSIX 1003.2. В спецификации POSIX 1003.2 задан минимум, необходимый для создания командной оболочки, а в спецификации Х/Open представлена более дружественная и мощная оболочка.

Немного о самом 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, если он был дополнительно настроен.

Q: я единственный пользователь своей системы и привык к su, зачем мне sudo?
A: отвечу вопросом на вопрос: если есть правильный sudo, зачем использовать устаревший su?

Как это ни парадоксально, команда 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 легко подскажет возможности дать определённым пользователям или группам только ограниченный набор прав. Впрочем, тут уже начинаются тонкости всамделишнего администрирования. Я же просто лишил своего двойника-экспериментатора доступа к любым административным действиям, дабы пресечь все его поползновения на этом поприще. Впрочем, даже это не всегда позволяет мне с ним справляться — подобно тому, как Тимур Шаов не в силах совладать со своим лирическим героем.