# sudo - выполнить от имени root

_Процессы и ресурсы · LinuxLab Knowledge Base_

**TL;DR:** `sudo` запускает команду от имени другого пользователя (обычно root)
по правилам в `/etc/sudoers`. Стандартный путь эскалации привилегий.


## Базовое применение

```bash
sudo whoami                       # → root (если ты в sudoers)
sudo apt update                   # запустить apt от root
sudo -u alice ls /home/alice      # -u: от имени конкретного юзера, не root
sudo -i                           # открыть полностью root-овую сессию
sudo -s                           # шелл от root, но с твоим окружением
sudo -E command                   # сохранить твоё окружение (env)
```

Спросит **твой** пароль (не root'а) - чтобы убедиться что это всё
ещё ты, а не кто-то перехвативший терминал. По умолчанию запоминает
на 5-15 минут (timestamp).

## /etc/sudoers - кто что может

Главный файл политики. **Никогда не редактируй прямо** - используй
`visudo`, который проверяет синтаксис перед сохранением (иначе
можно остаться без sudo вообще).

```bash
sudo visudo                       # /etc/sudoers
sudo visudo -f /etc/sudoers.d/myapp   # отдельный фрагмент
```

Современная практика - класть кастомные правила в `/etc/sudoers.d/*`,
не трогая базовый файл.

## Синтаксис правил

```
user host = (run-as) [tag:] command
```

Примеры:

```
alice ALL=(ALL) ALL                       # alice: всё, везде, от любого юзера
bob ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
# ↑ bob может перезапускать nginx без пароля, и больше ничего

%wheel ALL=(ALL) ALL                      # все в группе wheel - полные права
%dev ALL=(ALL) NOPASSWD: /usr/local/bin/deploy.sh
```

Тэги:
- **NOPASSWD:** - без запроса пароля
- **PASSWD:** - обратный
- **NOEXEC:** - запретить дочерним процессам делать exec*
- **SETENV:** - разрешить -E (передавать env)

## sudo -l - что мне разрешено

```bash
sudo -l                           # список доступных мне команд
sudo -l -U alice                  # что разрешено alice (нужен root для просмотра чужого)
```

Стандартная команда при онбординге на новый сервер: «что я тут могу».

## Логирование

Каждый вызов sudo пишет в `/var/log/auth.log` (Debian/Ubuntu) или
`journalctl _COMM=sudo`:

```bash
sudo journalctl _COMM=sudo --since today
# Apr 28 14:23:01 host sudo: alice : TTY=pts/0 ; PWD=/home/alice ;
#   USER=root ; COMMAND=/usr/bin/apt update
```

На прод-системах часто включают `sudoreplay` - пишет всё что произошло
в sudo-сессии (`Defaults log_input,log_output`).

## Безопасные паттерны

**1. Группы вместо индивидуальных юзеров.** Группа `wheel` или `sudo`
- стандартный способ дать «полные» права:

```bash
sudo usermod -aG sudo alice
```

**2. NOPASSWD только для конкретных команд.** Не давай NOPASSWD на ALL -
это эквивалентно «pwn без пароля если получили sudo-юзера».

**3. Не использовать `sudo` в скриптах с паролем в аргументах.**
Использовать NOPASSWD для конкретной команды или systemd-сервис от root.

**4. `Defaults requiretty` - устаревшая опция.** Раньше требовалось
работать только с tty (mitigation против credential-stealing).
Сейчас обычно отключена для удобства автоматизации.

## Альтернативы

- **doas** (OpenBSD-portable) - минималистичная замена sudo, конфиг
  проще; в Alpine/Arch как опция
- **pkexec** (polkit) - графическое окружение, по правилам polkit
- **systemd PrivateUsers/CAP_** - для сервисов лучше задавать
  capabilities в unit-файле, а не через sudo

## sudo vs su

`su -` тоже даёт root, но через **пароль root'а**. Современная
практика: вообще отключить root-пароль (`sudo passwd -l root`),
использовать только sudo. Это даёт:

- Per-user audit log (видно КТО что делал)
- Гранулярные правила (один может всё, другой - только nginx)
- Нет общего root-пароля который надо хранить

## sudo и [file-permissions](/kb/file-permissions.md) / [capabilities](/kb/capabilities.md)

Иногда sudo не нужен вообще. Если твоему бинарю нужно слушать порт 80:

- Плохо: `sudo ./myapp` - гипертрофированно, бинарь весь от root
- Лучше: `setcap cap_net_bind_service+ep ./myapp && ./myapp` - точечный
  capability ([capabilities](/kb/capabilities.md))
- Ещё лучше: systemd unit с `AmbientCapabilities=CAP_NET_BIND_SERVICE`,
  `User=myapp`

Sudo - это hammer. Часто нужна именно отвёртка.


## Команды

```bash
sudo -l
```
Что мне разрешено через sudo на этой машине - первый шаг при онбординге

```bash
sudo visudo -f /etc/sudoers.d/myapp
```
Безопасное редактирование политик с проверкой синтаксиса

```bash
sudo journalctl _COMM=sudo --since today
```
Кто что делал через sudo за сегодня - аудит

```bash
sudo -u alice -i
```
Открыть сессию как другой юзер (если разрешено в sudoers)

```bash
sudo -k
```
Сбросить кешированный credential - следующий sudo попросит пароль снова


## См. также

- [Linux capabilities - биты привилегий](/kb/capabilities.md)
- [File permissions: rwx и chmod](/kb/file-permissions.md)
- [Процесс и PID](/kb/process-and-pid.md)