Пользователи, группы и стартовые файлы

Оглавление серии

Учебные файлы пока принадлежат пользователю, который распаковал архив. У работающего веб-приложения обычно есть собственная учётная запись. Она определяет, что процесс может читать и изменять, а не то, как выглядит форма входа посетителя. Пользователь Linux и пользователь приложения — разные сущности. Таблица пользователей PostgreSQL не создаёт автоматически системные аккаунты и не назначает права на каталоги сервера.

Для DeskQueue Ops будем различать оператора лаборатории и служебную запись deskqueue. Оператор входит в систему и читает наблюдения. Служба запускает приложение и имеет доступ только к необходимым путям. В этой главе составим описание ролей и изучим механизм стартовых файлов. Создание системной службы появится позже; сейчас не требуется менять настройки настоящего хостинга.

Чья команда выполняется

Начните с текущей записи. Команда id показывает числовые идентификаторы и группы, а whoami — имя эффективного пользователя. Эти сведения помогают объяснить, почему одна и та же операция доступна в одном сеансе и недоступна в другом.

whoami
id
getent passwd deskqueue
getent group deskqueue

Отсутствие вывода для deskqueue означает, что запись не найдена через настроенный механизм разрешения имён. Не делайте сразу вывод, что приложение повреждено: в начальной лаборатории она ещё не создавалась. getent полезнее чтения одного локального файла, когда система может получать записи и из других источников. Само наличие имени тоже не подтверждает успешный запуск процесса.

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

Группа выражает общий доступ

Группа позволяет объединить пользователей для определённой задачи. Например, оператору можно дать чтение диагностических данных, не превращая его в владельца всего приложения. У записи есть основная и дополнительные группы. Добавление в группу не всегда меняет уже работающий сеанс; новые сведения обычно должны попасть в контекст нового входа или процесса.

В config/accounts.md записан договор нашей лаборатории: служба deskqueue читает выпуск, пишет только в выделенное рабочее хранилище и не получает интерактивный вход. Оператор управляет выпуском отдельным действием. Это описание не создаёт права само по себе. Следующий урок свяжет роли с владельцами каталогов и битами доступа, чтобы договор стал проверяемым.

Не используйте одну общую учётную запись для всех человеческих действий только ради удобства. В журнале будет сложнее установить, кто изменил настройку. У служебной записи другая задача: она представляет один процесс или группу связанных процессов. Такое разделение помогает ограничить последствия ошибки приложения и сохранить понятное происхождение административных изменений.

Повышение прав относится к действию

sudo запускает разрешённую операцию от другого пользователя согласно политике системы. Оно не делает любые аргументы команды правильными. Перед изменением системного каталога всё равно нужно установить путь и назначение файла. В нашей лаборатории большинство наблюдений доступно без повышенных прав; будем добавлять их только там, где задача действительно относится к системному объекту.

Сравните чтение config/accounts.md и создание системной записи. Первое относится к обычной рабочей папке. Второе меняет базу учётных записей Linux. Поэтому в stages/06/README.md системное действие вынесено в отдельную необязательную часть для выделенной машины. При подготовке серии оно не выполнялось, и наличие соответствующего описания не означает, что аккаунт уже создан.

Для будущей службы может использоваться системная запись с отдельной группой, без обычного домашнего каталога и с оболочкой, запрещающей интерактивный вход. Конкретную команду нужно читать вместе с условиями создания. В справке useradd различаются системный аккаунт, домашний каталог и выбранная оболочка; это независимые параметры, а не один переключатель безопасности.

Откуда берутся файлы нового пользователя

Когда создаётся домашний каталог обычного пользователя, стартовые файлы могут копироваться из каталога skeleton. В профиле Ubuntu стандартное место — /etc/skel. Там часто находятся скрытые настройки оболочки. Посмотрите список, затем сравните его с собственным домашним каталогом. Эти команды только читают файлы.

ls -la /etc/skel
ls -la ~

Такое копирование даёт начальное состояние, а не постоянную синхронизацию. Если изменить файл в skeleton после создания пользователя, его существующая копия сама не обновится. Для сопровождения множества записей требуется отдельный способ управления конфигурацией. Иначе изменения будут зависеть от даты создания аккаунта, хотя имена настроек выглядят одинаково.

В архиве есть собственный fixtures/skel-demo с коротким README для оператора. Мы не заменяем им системный /etc/skel: изучаем идею на обычном каталоге. В отдельной машине создание нового учебного пользователя с параметрами -m и -k могло бы использовать этот источник. Но для понимания механизма достаточно разобрать, какие файлы должны попасть в новый домашний каталог и какие останутся общими.

Стартовый набор имеет аудиторию

Общий README с путями лаборатории подходит для новых операторов. Пароль базы или личный SSH-ключ не подходит: каждый новый аккаунт получил бы одну и ту же копию, а источник мог бы быть доступен для чтения другим пользователям. Также настройки администратора базы не обязательно нужны редактору или оператору просмотра. Состав набора определяется ролью, а не желанием положить туда всё удобное.

Стартовые сценарии требуют отдельного внимания. Файл, который автоматически читается при входе, может выполнять команды. Поэтому одинаковое имя .bashrc не означает, что это безобидный текстовый документ. В нашей демонстрации README объясняет пути и не запускает действия. Это позволяет изучить распространение файлов, не смешивая его с автоматическим изменением сеанса.

Если после входа программа оказалась доступна только одному пользователю, сравните его группы, домашние настройки и PATH. Возможно, различие возникло в стартовом наборе, а не в установленном пакете. Такие проверки продолжают подход первых уроков: выясняем контекст и договор, затем меняем конкретную настройку. Массовое копирование чужих dotfiles скрывает причину и усложняет восстановление.

Результат главы — описание оператора и служебной записи, понимание числового владельца и группы, а также ясная граница /etc/skel. Мы ещё не считаем эти роли реализованными на сервере. Следующий шаг покажет, как доступ определяется для файлов и каталогов и почему разрешение чтения файла не всегда позволяет добраться до него по пути.