Линукс
Linux: Пользователи и группы
Вторая часть серии о Linux для DevOps и DevSecOps — разбираем, как устроены пользователи и группы, UID/GID, /etc/passwd и shadow, sudo, безопасность и реальные сценарии администрирования.
1. Введение
Продолжаем прохождение linux! Сразу уточню что статья может обновляться после адекватной критики и уточнений от сообщества Хабра(там где офицально статья была опубликована от opensophy), свежие обновления всегда происходят на opensophy.com, если вы только начинаете изучать линукс или хотите освежить память можете вернуться в прошлую серию рубрики ”Учим Linux: Файлы, навигация и поиск”. В этой части я попытался расписать довольно кратко т.к. информации и так много и тот же новичок может не сразу все выучить но по комментариям из Хабра я буду создавать что-то вроде чеклиста оперативных вопросов(это если я пропустил что-то из важной информации). Приступим.
Серия рубрик в основном под Ubuntu/Debian
2. Как Linux идентифицирует пользователя
2.1 Username vs UID
Ядро Linux работает исключительно с числами. UID (User Identifier) — числовой идентификатор пользователя (обычно 32-битный). Имя пользователя (username) — лишь человекочитаемый псевдоним, который инструменты вроде ls или ps подставляют при выводе, обращаясь к /etc/passwd.
⚠️ Если удалить пользователя и создать нового с тем же именем, но другим UID — новый пользователь не получит доступ к старым файлам. Права привязаны к UID, а не к имени.(А ВОТ ЕСЛИ ВЫ ПРИВЯЖЕТЕ к UID ТО ПОЛУЧИТ ДОСТУП К СТАРЫМ ФАЙЛАМ. Вроде очевидно но учитывайте этот момент)
2.2 Основные атрибуты пользователя
| Атрибут | Описание | Пример |
|---|---|---|
| username | Имя для входа и отображения | deployer |
| UID | Числовой идентификатор | 1001 |
| GID | Первичная группа | 1001 |
| home | Домашний каталог | /home/deployer |
| shell | Интерактивная оболочка | /bin/bash |
| GECOS | Комментарий (имя, телефон, …) | Ivan Petrov,, |
2.3 Быстрая диагностика
Первое, что можно сделать при входе на незнакомый сервер — проверить себя:
✅
getentпредпочтительнее прямого чтения/etc/passwd, потому что он учитывает LDAP, NIS и другие NSS-источники — корректно работает в корпоративной среде.
3. Модель доступа: пользователь → система
3.1 «Всё есть файл»
Каждый объект в Linux — файл, директория, устройство, сокет — имеет владельца (owner) и группу (group). Это метаданные хранятся прямо в inode.
3.2 Упрощённая модель проверки прав
Ядро идёт слева направо и останавливается на первом совпадении. Если UID процесса совпадает с owner файла — применяются только права owner, права group уже не проверяются.
ℹ️ Подробный разбор битов
rwx, SUID/SGID/Sticky bit и ACL — в следующей статье «Права доступа».
4. Виды пользователей
4.1 Диапазоны UID
| Диапазон | Тип |
|---|---|
0 | root — суперпользователь. Обходит большинство проверок прав доступа, но не все |
1–999 | Системные пользователи — сервисы и демоны. Без интерактивного входа. |
1000+ | Обычные пользователи — реальные люди. useradd назначает UID ≥ 1000. |
65534 | nobody — минимальное доверие. NFS, sshd, sandbox-изоляция. |
Диапазоны настраиваются в /etc/login.defs:
(обычно: системные <1000, обычные ≥1000)
4.2 Системные пользователи и nologin
Сервисы типа nginx, postgres, redis работают от имени собственного системного пользователя. У таких пользователей в качестве shell прописан /usr/sbin/nologin или /bin/false — интерактивный вход заблокирован.
4.3 root и nobody — крайности спектра
root (UID 0) — полный контроль над системой. Ядро не проверяет права доступа. Может монтировать ФС, загружать модули ядра, убивать любые процессы, читать любые файлы. При компрометации — полная потеря системы.
nobody (UID 65534) — минимальные привилегии. Не владеет ни одним файлом. Используется как «безопасный» контекст для untrusted-кода: NFS-маппинг, CGI-процессы, sandbox-изоляция.
nobody = 65534 — не всегда (может быть nfsnobody / UID может отличаться)
5. Группы
5.1 Зачем нужны группы
Группы — механизм коллективного доступа. Вместо раздачи прав каждому пользователю индивидуально, достаточно добавить нужных людей в группу и выдать права группе. Классический пример: группа docker открывает доступ к сокету Docker без sudo.
5.2 Первичная и дополнительные группы
| Тип | Хранится в | Назначение |
|---|---|---|
| Primary (GID) | /etc/passwd, поле 4 | GID новых создаваемых файлов. Одна на пользователя. |
| Supplementary | /etc/group | Дополнительные права. Ограничение зависит от системы (обычно десятки тысяч). |
5.3 Проверка членства
6. Где хранится информация
6.1 /etc/passwd — реестр пользователей
Читаемый всеми файл. Пароля здесь нет — поле пароля содержит x, хеш находится в /etc/shadow.
| Поле | Содержимое |
|---|---|
| 1 | Username |
| 2 | Пароль — всегда x, хеш в shadow |
| 3 | UID |
| 4 | GID (первичная группа) |
| 5 | GECOS — комментарий (имя, телефон, …) |
| 6 | Домашний каталог |
| 7 | Логин-шелл |
По поводу “x”: когда-то давно пароль мог храниться здесь в зашифрованном виде, но такая концепция не была признана безопасной.
это примерно выглядело так:
Раньше: хеш пароля реально хранился прямо в /etc/passwd файл был:
- читаем всеми ❗
- потому что нужен для работы системы (UID → username)
В итоге:
- любой пользователь мог читать хеши
- и пытаться их брутфорсить офлайн
Поэтому позже была введена система shadow passwords: поле пароля в /etc/passwd заменили на x, а сами хеши перенесли в защищённый файл /etc/shadow, доступный только root.
6.2 /etc/shadow — хеши паролей
Доступен только root (и группе shadow). Содержит хеш пароля с солью и параметры устаревания.
| Поле | Описание |
|---|---|
$6$... | $6$ = SHA-512. Далее: rounds, salt, хеш. $y$ = yescrypt (современный.) |
19800 | Дата последней смены (дни с 1970-01-01) |
0 | Мин. дней до следующей смены |
99999 | Макс. срок действия (99999 ≈ никогда) |
7 | Предупреждение за N дней до истечения |
! или * | Заблокированный аккаунт |
Можно еще уточнить что формат хеша в /etc/shadow зависит от системы и настроек тк $y$ используется не везде(следует уточнять в зависимости от ОС)
6.3 /etc/group
| Поле | Содержимое |
|---|---|
| 1 | Название группы |
| 2 | Пароль группы (всегда x) |
| 3 | GID |
| 4 | Список supplementary-пользователей |
6.4 /etc/gshadow
Хеши паролей групп и список администраторов групп. Нужен ~редко — актуален при использовании newgrp с паролем.
6.5 Безопасное редактирование
🚨 Никогда не редактируй
/etc/passwd,/etc/shadow,/etc/groupнапрямую через nano или vim. При параллельном изменении возможна гонка условий и повреждение файла.
7. Создание пользователей
7.1 useradd — параметры
| Ключ | Описание | Пример |
|---|---|---|
-m | Создать домашний каталог | -m |
-s | Логин-шелл | -s /bin/bash |
-G | Дополнительные группы (через запятую) | -G sudo,docker |
-g | Первичная группа (GID или имя) | -g www-data |
-u | Явно задать UID | -u 1500 |
-c | Комментарий (GECOS) | -c "Ivan Petrov" |
-d | Путь к home (если не стандартный) | -d /opt/service |
-e | Дата истечения аккаунта (YYYY-MM-DD) | -e 2025-12-31 |
-r | Системный пользователь (UID из sys-диапазона) | -r |
-b | Базовый каталог (вместо /home) | -b /srv |
-k | Каталог-шаблон вместо /etc/skel | -k /opt/skel |
-f | Дней неактивности после устаревания пароля до блокировки | -f 7 |
7.2 Установка пароля
7.3 Что происходит под капотом при useradd -m
- Запись в
/etc/passwd - Запись в
/etc/shadow(заблокирована до установки пароля) - Запись в
/etc/group(создаётся одноимённая primary-группа) mkdir /home/usernamecp -r /etc/skel/* /home/usernamechown -R user:user /home/username
8. Окружение пользователя
8.1 /etc/skel — шаблонные файлы
При создании пользователя с флагом -m содержимое /etc/skel копируется в home. Удобный механизм для стандартизации окружения.
8.2 Глобальные настройки
| Файл | Описание |
|---|---|
/etc/default/useradd | Дефолты для useradd: GROUP, HOME, SHELL, SKEL, INACTIVE |
/etc/login.defs | Диапазоны UID/GID, политика паролей, umask, HOME_MODE |
/etc/profile | Env-переменные для всех пользователей при логин-сессии |
/etc/profile.d/*.sh | Модульные скрипты из /etc/profile (предпочтительный способ) |
/etc/bash.bashrc | Глобальный bashrc для интерактивных шеллов (Debian/Ubuntu) |
9. umask — права по умолчанию
umask — маска, вычитаемая из максимальных прав при создании файлов и директорий. Максимум для файлов — 666, для директорий — 777.
ℹ️
umaskработает как побитовая маска исключения:666 & ~022 = 644. Простое вычитание при нестандартных значениях даст неверный результат.
10. Изменение пользователей
10.1 usermod
🚨 Флаг
-Gбез-aзаменяет все дополнительные группы. Пользователь потеряет все группы, включаяsudo. Всегда используй-aG.
10.2 chsh — смена оболочки
10.3 Блокировка и разблокировка
⚠️ Блокировка через
passwd -lзапрещает вход по паролю, но не блокирует SSH по ключу. Для полной блокировки: дополнительноusermod -s /usr/sbin/nologin ivanилиusermod -e 1 ivan.
11. Удаление пользователей
11.1 userdel
11.2 Риски при удалении
| Риск | Последствие | Защита |
|---|---|---|
| Потеря данных | Файлы в home безвозвратно удалены | Бэкап перед userdel -r |
| Orphaned files | Файлы вне home с UID без пользователя | find / -nouser до/после |
| UID reuse | Новый пользователь получает тот же UID → старые файлы | Явно задавать UID через -u |
| Запущенные сессии | userdel упадёт: «user is currently logged in» | pkill -u ivan && userdel -r ivan |
12. Управление группами
12.1 groupadd / groupmod / groupdel
12.2 Добавление пользователя в группу
⚠️ Изменения вступают в силу только при следующем входе. Для немедленного применения в текущей сессии:
12.3 Проверка
13. Привилегии: su vs sudo
13.1 su — переключение пользователя
su запускает новый шелл от имени другого пользователя, используя его пароль.
Разница su vs su -:
su— переключает UID, но сохраняет PATH и переменные текущего пользователяsu -— полный login shell: новый PATH, HOME, SHELL, выполняется~/.profileцелевого пользователя
⚠️ На Ubuntu по умолчанию у root нет пароля. Используем
sudo -iилиsudo su -вместоsu.
13.2 sudo — точечное делегирование прав
sudo выполняет одну команду с повышенными привилегиями, авторизуясь паролем самого пользователя и логируя каждое действие.
13.3 Настройка /etc/sudoers
🚨 Редактировать только через
visudo. Синтаксическая ошибка без visudo заблокирует весь sudo на системе.
Синтаксис строки: КТО ОТКУДА=(ОТ_КОГО) [NOPASSWD:] ЧТО
Модульная организация через /etc/sudoers.d/:
13.4 su vs sudo — когда что использовать
| Критерий | su | sudo ✓ |
|---|---|---|
| Авторизация | Пароль целевого пользователя | Свой пароль |
| Аудит | Нет гранулярного лога | Полный лог в syslog |
| Гранулярность | Полная смена identity | Конкретные команды с NOPASSWD |
| Автоматизация | Неудобно | Удобно: NOPASSWD для скриптов |
| Когда применять | Длительная сессия под другим пользователем | Production-серверы, разовые привилегированные операции |
