su и sudo: какая разница, полезные примеры

Чем отличаются su и sudo: простое объяснение, без занудства

Помню как в далеком 2006 или 2007 году я впервые столкнулся с Linux. Ты сидишь перед терминалом, чувствуешь себя почти хакером, набираешь команду из мануала — и вдруг тебе выдают в ответ: “Permission denied”. Вот оно, первое столкновение с суровой системой прав. Linux — как строгий преподаватель: без допуска — ни шагу. И, честно говоря, это не зря. Именно благодаря этому он и считается одной из самых безопасных систем.

Но рано или поздно тебе всё равно нужно сделать что-то, что обычному пользователю не положено. Например, установить обновления или перезапустить сервер. И вот тут на сцену выходят два старых знакомых — su и sudo. И хотя звучат они похоже, на практике — это две совершенно разные философии управления системой.

Когда-то всё решал su

В старые времена всё было просто: хочешь что-то изменить в системе — становись root. Команда su (сокращение от substitute user) позволяла буквально «влезть в шкуру» другого пользователя, чаще всего — суперпользователя. Пишешь в терминале:

su -
Password: [вводишь root-пароль]

И всё. Теперь ты бог этой машины. Можешь делать что угодно — от удаления системных файлов до форматирования дисков. Проблема в том, что иногда ты действительно это делаешь… случайно.

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

sudo: тот же root, только с ремнём безопасности

Потом в моей жизни появился sudo — и мир Linux стал чуть безопаснее. Аббревиатура расшифровывается как superuser do, то есть «выполни от имени суперпользователя». Звучит просто, но идея гениальна: теперь тебе не нужно знать root-пароль. Ты используешь свой собственный пароль, а система проверяет — можно ли тебе выполнять конкретную команду.

Пример классический:

sudo apt update
[sudo] password for user: [твой пароль]

И вуаля — обновления пошли. Но при этом всё логируется. Каждая команда, выполненная через sudo, записывается в журнал. То есть если кто-то что-то сломал, можно точно узнать, кто именно это сделал (и когда). Такая себе цифровая камера наблюдения.

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

Кто вообще решает, кому можно использовать sudo?

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

sudo visudo


Она открывает этот файл в безопасном режиме. Если где-то накосячишь, система не даст сохранить. Умно придумано. По умолчанию там есть примерно такая строчка:

root ALL=(ALL:ALL) ALL


Что это значит? Что пользователь root может выполнять любые команды, на любом компьютере, от имени любого пользователя. Король, одним словом.

Как добавить кого-то в sudo?

Если хочешь дать кому-то административные права, можно просто добавить его в группу sudo:

adduser bob sudo

После этого bob сможет использовать команду sudo, и система будет считать, что ему можно доверять. Но вот тут начинаются нюансы. Давать полные права всем подряд — идея так себе. Один невнимательный пользователь — и вся система летит к чертям.

Как не превратить sudo в хаос

Самая большая сила sudo — это гибкость. Ты можешь настроить, какие именно команды разрешено выполнять конкретному пользователю. Например, дать администратору баз данных право перезапускать только MySQL, но не трогать ничего другого.

Примерно так:

mark beta.database_server.com=(ALL) /usr/sbin/service mysql restart


А вот ещё примеры:

1. Разрешить пользователю перезапускать только веб-сервер

mark ALL=(root) /bin/systemctl restart apache2, /bin/systemctl restart nginx

Пользователь mark может перезапускать Apache и Nginx, но больше ничего. Полезно, если у вас есть веб-мастер, которому не стоит доверять всю систему — только обслуживание сайта.

2. Разрешить администратору базы данных управлять только MySQL

dbadmin ALL=(root) /usr/bin/systemctl restart mysql, /usr/bin/systemctl status mysql

Теперь dbadmin может перезапускать MySQL и смотреть его статус, но не сможет, скажем, выключить сервер. Минимум риска, максимум пользы.

3. Разрешить пользователю обновлять пакеты, но не устанавливать новые

adam ALL=(root) /usr/bin/apt update, /usr/bin/apt upgrade

Это идеальный вариант для системных операторов: можно поддерживать систему в актуальном состоянии, но не ставить сомнительные пакеты с непонятными зависимостями.

4. Разрешить пользователю читать системные логи

anna ALL=(root) /bin/cat /var/log/syslog, /bin/cat /var/log/auth.log

Если у тебя есть специалист, который отслеживает ошибки, но не должен трогать настройки — вот это то, что нужно. Она сможет смотреть логи, но не менять файлы.

5. Разрешить доступ к конкретным скриптам

tech ALL=(root) /home/admin/scripts/backup.sh, /home/admin/scripts/check_status.sh

Пусть твой техник запускает бэкапы и проверки статуса — но не имеет права лезть в систему напрямую. Главное — не забудь прописать полный путь к скриптам.

6. Разрешить использование утилиты `systemctl` только с конкретными сервисами

alex ALL=(root) /bin/systemctl start docker, /bin/systemctl stop docker, /bin/systemctl restart docker

Классика DevOps-жизни: дать человеку перезапускать контейнеры, но не всю систему. Docker жив — всё хорошо. Перезапуск — по разрешению.

7. Разрешить выполнять сетевые проверки без пароля

netops ALL=(root) NOPASSWD: /bin/ping, /usr/bin/traceroute, /usr/bin/netstat

Если сетевик делает диагностику десятки раз в день — заставлять его вводить пароль каждый раз просто издевательство. NOPASSWD экономит нервы (но злоупотреблять не стоит!).

8. Создать алиасы для команд и пользователей

User_Alias ADMINS = tom, jerry, adam Cmnd_Alias WEBCMDS = /bin/systemctl restart apache2, /bin/systemctl restart nginx ADMINS ALL=(root) WEBCMDS

Теперь все пользователи из группы ADMINS могут перезапускать веб-серверы. Очень удобно, когда нужно дать одной команде одинаковые права.

9. Ограничить доступ к определённой директории

maria ALL=(root) /bin/ls /var/www, /bin/cat /var/www/*, /usr/bin/du -sh /var/www

Теперь maria может проверять содержимое папки сайта и смотреть размер, но не может ничего удалить или изменить. Это прям спасение, если кто-то любит «посмотреть, как устроено» и случайно всё ломает.

10. Разрешить пользователю выключать компьютер (например, для офиса)

officeuser ALL=(root) /sbin/poweroff, /sbin/reboot

Если у тебя в офисе Linux-машина, и нужно позволить обычным сотрудникам безопасно выключать её — вот решение. Больше не придётся объяснять, что «вот эта кнопка не работает, потому что нужны права root».

11. Разрешить группе администраторов выполнять всё, кроме удаления файлов

Defaults!rm !authenticate ADMINS ALL=(root) ALL, !/bin/rm, !/bin/rm -rf

Да, это возможно: ты можешь разрешить всё, кроме команды удаления. Очень полезно, если у тебя неопытные админы и ты не хочешь потом восстанавливать систему из пепла.

12. Дать пользователю возможность только перезапускать службу SSH

security ALL=(root) /bin/systemctl restart ssh, /bin/systemctl status ssh

Идеально для службы безопасности — можно перезапустить SSH, если сессии зависли, но при этом нет доступа ни к чему лишнему.

13. Разрешить sudo без пароля для скриптов автоматизации

deploy ALL=(root) NOPASSWD: /usr/bin/git pull, /usr/bin/systemctl restart myapp

Когда у тебя CI/CD или cron-задачи, пароль — это лишнее. NOPASSWD тут нужен, чтобы всё выполнялось без вмешательства человека.

14. Разрешить пользователю выполнять команду под другим пользователем

alex ALL=(www-data) /usr/bin/ls /var/www, /usr/bin/touch /var/www/test.txt

Вот тут магия: alex сможет выполнять команды от имени www-data (то есть от имени веб-сервера). Полезно, если тебе нужно дать кому-то возможность менять файлы сайта, не раскрывая пароли root.

15. Ограничить sudo доступ по конкретному хосту

mark web01.setiwik.local=(root) /usr/bin/systemctl restart apache2

Теперь права действуют только на сервере web01.setiwik.local. Если этот же пользователь попробует запустить sudo на другой машине — получит отказ. Незаменимо, когда администраторов несколько, и у каждого свой сервер.

16. Разрешить только безопасные команды, запрещая всё остальное

bob ALL=(root) /usr/bin/top, /usr/bin/df -h, /usr/bin/free -m bob ALL=(root) !/bin/rm, !/bin/mv, !/bin/chmod, !/bin/chown

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

17. Запретить использование sudo без аргументов

Defaults!/usr/bin/sudo requiretty

Это настройка предотвращает запуск «пустого» sudo (когда кто-то просто пишет sudo и ждёт root-оболочку). Так можно избежать случайных ошибок и “привилегированных приключений”.

18. Дать пользователю права только на чтение sudoers

audit ALL=(root) /bin/cat /etc/sudoers

Аудитору может понадобиться проверить конфигурацию, но трогать её нельзя. Вот и решение — можно читать, нельзя писать. Как ревизор с фонариком, но без ключей от сейфа.

19. Разрешить запуск мониторинга системных процессов

monitor ALL=(root) /usr/bin/htop, /usr/bin/top, /usr/bin/ps aux

Тот случай, когда нужно наблюдать за системой в реальном времени. Безопасно, прозрачно, удобно — и без доступа к опасным командам.

20. Разрешить sudo без пароля только для выключения сервера

user ALL=(root) NOPASSWD: /sbin/poweroff, /sbin/reboot

Очень полезно на домашних серверах или медиацентрах. Обычный пользователь может выключить машину без лишних вводов паролей.

Антипример как не надо делать

john ALL=(ALL) ALL

Вот так делать не надо. Это даёт пользователю те же права, что и root, без ограничений. Можно, конечно, если ты полностью доверяешь человеку. Но практика показывает: в Linux доверие кончается быстрее, чем диск на /var.

Главное — не переборщи. Иначе получится «безопасность без пароля», а это такое себе.

sudo vs su: кто победил?

Если коротко: sudo. Практически все современные дистрибутивы (Ubuntu, Debian, Fedora и т. д.) используют именно его. su почти ушёл в прошлое — остался только у тех, кто любит «олдскул» или работает на серверах, где всё настроено вручную.

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

Из личного опыта

Как то я тестил права и настроил sudo. Далее решил «поиграться» и внезапно попытался удалить весь каталог /etc. Команда sudo не дала мне это сделать, так как в настройках я разрешил только пару конкретных команд. Соответственно сделал вывод:  да, эта штука действительно спасает.

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

Итог

Так что да, Linux действительно безопасен — но не потому, что «там вирусов нет», а потому, что он заставляет тебя думать, прежде чем что-то менять. su и sudo — это две стороны одной монеты: одна даёт тебе полную власть, другая — контроль и ответственность.

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

Вот и вся разница.

И да, если ты никогда не пользовался visudo — попробуй. Только не ломай систему. Серьёзно, я предупреждал.