_ТЕРМИНАЛ_ SU_ ИЛИ _SUDO_ ?


С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации 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. Являясь полной заменой susudo должна бы быть единственной командой переключения между пользователями, однако, как было сказано вначале, в настоящий момент это не так и все зачем-то изобретают дикие последовательности из 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 есть несколько преимуществ, ради которых стоит потрудиться набрать несколько лишних символов:

  • по умолчанию 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?


Как установить Расширение ADBLOCK (для браузера Chromium).

                      Stop - реклама!

            ПРОВЕРЬ

Безопасность компьютера

 


 







 



Ваш IP адрес

****************

Консольный конвертер файлов rpm в deb.pd
Adobe Acrobat Document 34.7 KB
Полное удаление программ в Linux.txt
Text Document 2.2 KB
НАСТРОЙКА ПЕЧАТИ.pdf
Adobe Acrobat Document 47.4 KB
УСТАНОВКА " Minitube " - 2.0-1~webupd8~precise0
Установка _ Minitube_2.0-1~webupd8~preci
Text Document 394 Bytes