Профессиональное управление пользователями и доступом в Linux: от основ к автоматизации

Архитектура идентификации: UID, GID и системные файлы конфигурации

Операционная система Linux абсолютно равнодушна к тому, как вас зовут. Для ядра системы не существует ни пользователя root, ни пользователя alice. Ядро — математический механизм, который оперирует исключительно числами. Если вы планируете автоматизировать управление доступом, первое, что нужно усвоить: имена созданы только для удобства людей, а реальная власть в системе базируется на числовых идентификаторах.

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

UID и GID: истинные лица пользователей

Каждому процессу и файлу в Linux назначен владелец. Этот владелец определяется двумя ключевыми числами:

• UID (User Identifier) — уникальный идентификатор пользователя.
• GID (Group Identifier) — уникальный идентификатор основной группы пользователя.

Когда вы вводите команду ls -l и видите, что файлом владеет alice, это лишь иллюзия, услужливо созданная утилитой ls. На самом деле файл принадлежит, например, UID $1001$. Утилита на лету «переводит» число в понятное имя.

В Linux существует строгая иерархия диапазонов UID:

Диапазон UID	Назначение	Описание
0	Суперпользователь (root)	Абсолютный властелин системы. Ядро предоставляет неограниченные права любому аккаунту с UID 0, независимо от его текстового имени.
1 – 999	Системные аккаунты	Используются для запуска служб (веб-сервер, база данных). Под ними нельзя войти в систему. Это изолирует процессы друг от друга ради безопасности.
$\geq 1000$	Обычные пользователи	Реальные люди (или автоматизированные скрипты), которым нужен доступ к оболочке. При написании bash-скриптов для аудита обычно фильтруют именно этот диапазон.

Мост между человеком и ядром: /etc/passwd

Если ядро понимает только числа, то как система узнает, что при вводе логина alice нужно использовать UID $1001$? Эту роль выполняет плоский текстовый файл /etc/passwd.

Это главная база данных аккаунтов в Linux. В ней нет никакой магии — это просто таблица, где разделителем колонок выступает двоеточие (:).

Давайте препарируем типичную строку из этого файла:

alice:x:1001:1001:Alice Smith,,,:/home/alice:/bin/bash

Каждая запись состоит ровно из семи полей:

1. Имя пользователя (alice) — логин для входа.
2. Пароль (x) — исторически здесь хранился зашифрованный пароль. Сейчас здесь всегда стоит буква x, указывающая, что пароль спрятан в другом, более безопасном месте.
3. UID (1001) — тот самый номер, который система использует под капотом.
4. GID (1001) — номер основной группы пользователя.
5. GECOS (Alice Smith,,,) — информационное поле. Обычно содержит полное имя, номер кабинета или рабочий телефон. Запятые разделяют эти метаданные.
6. Домашняя директория (/home/alice) — папка, в которую попадает пользователь сразу после успешного входа.
7. Оболочка (Shell) (/bin/bash) — программа, которая запускается при входе. Если здесь указать /usr/sbin/nologin, аккаунт будет существовать, но войти в него через терминал станет невозможно (так делают для системных служб).

Иллюзия команды useradd

Зная структуру /etc/passwd, вы получаете важный инсайт для автоматизации: команда useradd не делает ничего сверхъестественного. Это просто скрипт-обертка, который:

1. Находит первый свободный UID $\geq 1000$.
2. Добавляет новую строку в конец /etc/passwd.
3. Создает папку в /home и копирует туда базовые файлы.

Теоретически, вы можете создать пользователя вручную, просто открыв /etc/passwd в текстовом редакторе и дописав туда строку. Система примет этого пользователя как родного.

Эволюция безопасности: файл /etc/shadow

Вы обратили внимание на букву x во втором поле /etc/passwd?

На заре развития Unix зашифрованные пароли хранились прямо в /etc/passwd. Проблема заключалась в том, что этот файл должен быть доступен для чтения всем пользователям системы. Иначе команда ls не смогла бы прочитать файл, чтобы перевести UID владельца файла в имя, и система бы сломалась.

Когда вычислительные мощности выросли, злоумышленники начали просто копировать /etc/passwd и подбирать пароли на своих компьютерах методом перебора (брутфорс).

Решением стало разделение:

• Публичная информация (имена, UID, папки) осталась в /etc/passwd (доступен всем для чтения).
• Секретная информация (хэши паролей) переехала в файл /etc/shadow.

Файл /etc/shadow доступен для чтения только пользователю root. Обычный пользователь не может даже посмотреть, как выглядит зашифрованный пароль соседа.

Пример строки из /etc/shadow:

alice:$6$xyz123$vT...longhash...:19245:0:99999:7:::

Здесь поля также разделены двоеточиями, но их смысл связан исключительно с безопасностью:

1. Имя пользователя (alice) — для связи с /etc/passwd.
2. Хэш пароля ($6$...) — криптографический хэш. Если здесь стоит * или !, вход по паролю заблокирован (полезно для сервисных аккаунтов или при доступе только по SSH-ключам).
3. Дата изменения — количество дней с 1 января 1970 года, когда пароль менялся в последний раз.
4. Политики устаревания — последующие числовые поля определяют, через сколько дней пользователь обязан сменить пароль, за сколько дней его предупредить и когда заблокировать аккаунт окончательно.

Резюме

Архитектура идентификации в Linux элегантна в своей простоте. Вся сложная система прав доступа опирается на два плоских текстовых файла: /etc/passwd для маршрутизации имен в числа и /etc/shadow для безопасной аутентификации.

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

Управление группами и коллективный доступ к ресурсам

В каждой строке файла /etc/passwd за пользователем жестко закреплен один GID (Group Identifier). Если пользователь создает новый файл, система автоматически назначает этому файлу группу, соответствующую этому GID. Но в реальной инфраструктуре один сотрудник редко изолирован в рамках одной функции. Разработчику нужен доступ к логам веб-сервера, ключам деплоя и общим документам отдела. Если бы Linux ограничивался только одним GID на пользователя, организовать совместную работу было бы невозможно.

Проблема решается разделением групп на два типа: основную и дополнительные.

Архитектура членства: Primary и Supplementary

В Linux связь между пользователем и группами асимметрична. Ядро операционной системы четко разделяет роли групп в зависимости от того, какое действие пытается совершить пользователь.

Основная группа (Primary group) Это тот самый GID, который указан в четвертом поле /etc/passwd. У пользователя может быть только одна основная группа. Ее главная и единственная задача — выступать шаблоном по умолчанию. Когда пользователь создает новый файл или директорию, ядро присваивает этому объекту GID основной группы создателя. Основная группа отвечает за маршрутизацию новых данных.

Дополнительные группы (Supplementary groups) Их может быть множество (исторический лимит составлял 16, в современных ядрах — до 65536). Эти группы никак не влияют на создание новых файлов. Их задача — проверка прав доступа к уже существующим ресурсам. Когда пользователь пытается прочитать чужой файл, ядро проверяет, не совпадает ли GID этого файла с GID любой из дополнительных групп пользователя.

Анатомия файла /etc/group

Если основная группа хранится прямо в профиле пользователя (/etc/passwd), то где хранятся списки дополнительных групп? Для этого существует отдельная плоская база данных — файл /etc/group.

Структура этого файла похожа на /etc/passwd. Каждая строка описывает одну группу и состоит из четырех полей, разделенных двоеточием:

developers:x:1005:alice,bob,charlie

1. Имя группы (developers): Текстовое название для удобства администратора.
2. Пароль (x): Исторический рудимент. Раньше пользователи могли временно переключаться в чужую группу, введя ее пароль. Сейчас здесь стоит x, а хэши (если они вообще используются) вынесены в /etc/gshadow. В современной практике пароли на группы практически не применяются.
3. GID (1005): Числовой идентификатор. Именно с ним работает ядро при проверке доступа.
4. Список пользователей (alice,bob,charlie): Перечень логинов через запятую, без пробелов. Для этих пользователей данная группа является дополнительной.

Важный нюанс архитектуры: если для пользователя alice группа developers является основной (ее GID указан в /etc/passwd), логин alice не обязан присутствовать в четвертом поле файла /etc/group в строке developers. Ядро собирает полный список групп пользователя, объединяя данные из обоих файлов.

Управление членством: ловушка usermod

Поскольку конфигурация хранится в обычных текстовых файлах, вы можете редактировать /etc/group напрямую через vi или nano. Однако при автоматизации инфраструктуры или работе через скрипты используются специальные утилиты.

Основной инструмент для изменения параметров существующего пользователя — команда usermod. Чтобы добавить пользователя в дополнительную группу, используется комбинация флагов -a (append) и -G (groups).

usermod -aG docker alice

Эта команда безопасно допишет логин alice в конец строки группы docker в файле /etc/group.

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

Флаг -G сам по себе означает «установить точный список дополнительных групп». Если вы не используете флаг -a (добавить), утилита usermod перезапишет список. Пользователь будет удален из всех своих старых групп (например, wheel или developers) и останется только в той, которую вы указали. В продакшен-среде это мгновенно ломает доступы сотрудника или сервиса ко всем привычным ресурсам.

Проблема сессионного токена

Представьте ситуацию: вы успешно выполнили usermod -aG developers bob. Вы проверили файл /etc/group — логин bob там есть. Боб пытается открыть файл, принадлежащий группе developers, но система выдает ошибку «Permission denied».

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

Когда Боб вводит логин и пароль, процесс /bin/login аутентифицирует его и обращается к файлам /etc/passwd и /etc/group. На основе этих файлов ядро формирует в оперативной памяти сессионный токен (credentials) — структуру данных, содержащую UID Боба и полный список его GID. Затем запускается командная оболочка (например, /bin/bash), которая наследует этот токен. Все программы, которые Боб запускает из этой оболочки, также наследуют этот слепок прав.

Если администратор меняет файл /etc/group, изменения происходят на жестком диске. Но запущенная оболочка Боба и ее токен в оперативной памяти не обновляются динамически. Ядро не сканирует систему, чтобы на лету поменять права всем запущенным процессам Боба.

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

1. Полный выход (Log out / Log in): Боб завершает сессию и заходит заново.
2. Команда newgrp: Боб может выполнить команду newgrp developers. Эта утилита запустит новую дочернюю оболочку (subshell) с обновленным токеном, где группа developers станет активной (и даже временно станет основной для этой конкретной сессии).

Понимание того, как пользователи объединяются в группы и почему ядро использует сессионные токены, подводит нас к главному вопросу: как именно эти UID и GID соотносятся с самими файлами? Для этого система использует матрицу из девяти битов, определяющую, что создатель, его группа и все остальные могут делать с ресурсом.

Пользователь alice и пользователь bob состоят в одной дополнительной группе developers. Алиса создает скрипт deploy.sh и просит Боба внести в него правки. Боб открывает файл, но получает ошибку «Permission denied». Наличие общего сессионного токена с GID группы developers — это лишь половина дела. Ядро знает, в каких группах состоит Боб, но оно не позволит ему изменить файл, пока сам файл явно не разрешит это сделать членам группы.

В Linux принадлежность к группе не дает автоматического доступа ко всем файлам этой группы. Права доступа всегда привязаны к самому объекту файловой системы через матрицу из девяти битов.

Девятибитная матрица UGO

Каждый файл и директория в Linux хранит информацию о том, кому они принадлежат (UID владельца и GID группы), и матрицу прав доступа, разделенную на три категории: User (владелец), Group (группа) и Other (остальные).

Если выполнить команду ls -l, мы увидим строку вида -rwxr-xr--. Первый символ указывает на тип объекта (- для файла, d для директории), а следующие девять символов — это и есть матрица UGO, разбитая на три тройки:

1. User (rwx): права пользователя-владельца.
2. Group (r-x): права целевой группы файла.
3. Other (r--): права всех остальных пользователей системы, которые не являются владельцами и не входят в целевую группу.

Внутри каждой тройки позиция строго фиксирована: чтение (r), запись (w) и выполнение (x). Если право отсутствует, на его месте стоит дефис (-).

Алгоритм принятия решения ядром (First Match)

Самая частая ошибка при проектировании доступов — считать, что права суммируются. Ядро Linux проверяет права строго последовательно и останавливается при первом же совпадении.

1. Ядро сравнивает UID процесса (пользователя) с UID владельца файла. Если они совпадают, применяются права User. Проверка завершается. Группа и остальные игнорируются.
2. Если UID не совпал, ядро проверяет, есть ли GID файла в сессионном токене пользователя. Если да, применяются права Group. Проверка завершается.
3. Если ни UID, ни GID не совпали, применяются права Other.

Семантика r, w, x: файлы против директорий

Буквы r, w и x означают совершенно разные действия в зависимости от того, к чему они применяются — к обычному файлу или к директории.

Право	Для файла	Для директории
r (read)	Чтение содержимого файла (cat, less).	Чтение списка файлов в директории (ls). Но без права x вы не узнаете метаданные файлов (размер, владельца).
w (write)	Изменение содержимого файла.	Создание, удаление и переименование файлов внутри директории. Требует наличия права x.
x (execute)	Запуск файла как программы или скрипта.	Право «входа» в директорию (cd) и доступа к её содержимому (stat). Это поисковый бит.

Если у директории снять бит x, она превращается в «черный ящик». Даже если у вас есть право r на директорию и полные права на файлы внутри нее, вы не сможете прочитать ни один файл, потому что ядро заблокирует вам прохождение через саму директорию.

Восьмеричная нотация (Octal)

Для автоматизации и работы со скриптами строковый формат rwxr-xr-- неудобен. Вместо него используется восьмеричное представление, где каждое право имеет числовой вес:

• $r = 4$
• $w = 2$
• $x = 1$

Чтобы получить цифру для категории, веса складываются по формуле $P = r + w + x$. Например, для прав r-x вычисление выглядит так: $4 + 0 + 1 = 5$.

Разберем классический пример прав на веб-директорию: rwxr-xr-x.

1. User: $4 + 2 + 1 = 7$
2. Group: $4 + 0 + 1 = 5$
3. Other: $4 + 0 + 1 = 5$

Итоговые права записываются как 755. Команда для их применения: chmod 755 /var/www/html.

Специальные биты: выход за рамки классической модели

Классической модели UGO хватает для 90% задач, но она пасует перед сложными сценариями. Например, как обычный пользователь меняет свой пароль? Хэши лежат в /etc/shadow, куда доступ есть только у root (права 640). Команда passwd должна записать туда новый хэш, но от имени обычного пользователя ядро заблокирует запись.

Для решения таких архитектурных противоречий существуют три специальных бита. Они добавляют четвертую цифру в начало восьмеричной маски (например, 4755).

SUID (Set User ID) — вес 4000

Отображается как s вместо x в правах владельца (rwsr-xr-x). При запуске исполняемого файла с установленным SUID-битом, процесс получает эффективный UID не того пользователя, который его запустил, а владельца файла.

Утилита /usr/bin/passwd принадлежит root и имеет SUID-бит. Когда Алиса запускает её, процесс временно получает права root, что позволяет ему легитимно записать данные в /etc/shadow. Это контролируемое и узконаправленное повышение привилегий.

SGID (Set Group ID) — вес 2000

Отображается как s вместо x в правах группы (rwxr-sr-x). На исполняемых файлах работает аналогично SUID, но для группы. Однако главная суперсила SGID раскрывается при применении к директориям.

Вспомним механику основной (Primary) группы: когда Алиса создает файл, ему присваивается её основная группа (например, alice). Если команда разработчиков работает в общей папке /opt/project, Алиса создаст там файл, и Боб не сможет его изменить, так как файл получит группу alice, а не общую developers.

Если на директорию /opt/project повесить SGID-бит, поведение ядра меняется: все новые файлы и поддиректории, созданные внутри, будут наследовать GID этой директории, а не основную группу создателя.

Sticky Bit — вес 1000

Отображается как t вместо x в правах остальных (rwxrwxrwt). Применяется исключительно к директориям, открытым на запись для множества пользователей (например, /tmp).

По правилам классической модели, право w на директорию позволяет удалять из нее любые файлы. Если у папки права 777, Алиса может удалить файл Боба. Sticky Bit меняет это правило: удалять и переименовывать файлы в такой директории может только владелец файла (или root).

Синтез: идеальная общая директория

Понимание классической модели и специальных битов позволяет конструировать безопасные рабочие пространства. Если нам нужно создать папку /data/shared для группы analytics, где все могут создавать и редактировать файлы, но никто не может удалять чужие документы, мы собираем права как конструктор:

1. Базовые права: владельцу (root) всё, группе всё, остальным ничего — 770.
2. Чтобы файлы наследовали группу analytics, добавляем SGID (вес 2000).
3. Чтобы запретить удаление чужих файлов, добавляем Sticky Bit (вес 1000).

Суммируем специальные биты: $2000 + 1000 = 3000$. Итоговая команда: chmod 3770 /data/shared. В строковом виде это будет выглядеть как drwxrws--t. Это эталонный паттерн для корпоративных файловых помоек и общих рабочих пространств, который полностью автоматизирует правильное распределение прав при создании новых файлов.