Вопрос или проблема
В /etc/group есть группа users с числовым идентификатором группы 100.
Когда я устанавливаю RHEL 7, 8 или 9, это не позволяет мне создать начального пользователя с первичным идентификатором группы 100. Графический интерфейс всегда возвращается к 1000, создавая новую группу с именем пользователя в качестве нового имени группы. Мне это не нравится.
Почему установщик RHEL (и предположительно любой другой в настоящее время) не позволяет установить первичный GID этого пользователя во время установки на gid=100?
Я предполагаю, что нормально иметь примерно 50+ локальных пользователей в системе, определенных в /etc/passwd с gid 100 users. Есть ли у этого какие-то недостатки? Какова конвенция и история gid 100 users? Создает ли нахождение users с низким gid (100) по сравнению с 1000 и выше какие-либо проблемы?
графический интерфейс возвращается к 1000, создавая новую группу с именем пользователя в качестве нового имени группы.
Я бы сказал, что существует противоположная зависимость, чем ту, которую вы предполагаете. Создание групп не связано со значением GID. Вместо этого оно вызывает GID – создание новой группы с именем пользователя это то, для чего была запрограммирована программа установки, и она выбирает GID в соответствии с этой целью, а не наоборот.
Использование индивидуальных “пользовательских групп” с именем пользователя в качестве имени группы является старой практикой (инструментарий ‘shadow’ называл это “часто встречающимся в дистрибутивах Linux” еще в 1999 году).
Насколько мне удалось исследовать без возможности путешествия во времени, изначальная цель, вероятно, заключалась в том, чтобы позволить 027 или даже 07 в качестве умолчания для umask системы; так, чтобы файлы, создаваемые в назначенных папках, принадлежащих определенным группам (скажем, /nfs/projects/abc, принадлежащих ‘root:projectabc’ и отмеченных +setgid), автоматически были доступны для членов этой ‘projectabc’ – но без того, чтобы все другие файлы автоматически были доступны для членов стандартной группы ‘users’.
Вкратце, идея в том, что файлы пользователей будут rwx rwx --- по умолчанию, а индивидуальные группировки пользователей позволяют таким файлам оставаться приватными по умолчанию.
(Это, похоже, предшествует реализации POSIX ACLs, где ‘default ACL’ для g::rwx мог быть установлен на уровне директории вместо необходимости глобального umask.)
Поскольку установщик был запрограммирован безусловно создавать группу, он ожидает получить идентификатор группы, который еще не существует, и, поскольку, вероятно, был написан с учетом модели “usergroup”, устанавливает ожидаемый диапазон GID, соответствующий стандартному диапазону UID (0-999 является “системным” диапазоном UID). Ранее диапазон на Fedora/RedHat начинался с 500, и в Anaconda GUI были установлены ограничения ввода соответственно.
Ручное изменение вашего первичного GID на users(100) через usermod (и отключение автоматического создания пользовательских групп через /etc/login.defs для будущих вызовов useradd) не должно вызывать проблем – по крайней мере, если тот же login.defs также указывает достаточно ограничительный umask (077 или 022, если вы хотите традиционный, в отличие от 007). Помимо файлов, я не могу придумать никаких других ресурсов, которые дали бы нежелательный доступ из-за нахождения в общей первичной группе.
Ответ или решение
Введение:
Когда вы устанавливаете операционную систему, особенно такую как RHEL (Red Hat Enterprise Linux), вам предоставляется возможность создать начального пользователя. Однако, практика современных дистрибутивов отличается определенными нюансами, которые могут вызвать недоумение у пользователей, ожидающих традиционные подходы. Одним из таких нюансов является невозможность указать первичную группу пользователя с GID 100 во время установки. Давайте рассмотрим, почему это так, опираясь на исторические и технические аспекты.
Теоретическая часть:
Традиционно, в Unix-подобных системах, таких как Linux, пользователи и группы управляются через файлы /etc/passwd и /etc/group. Каждой группе и пользователю присваивается уникальный идентификатор – UID для пользователей и GID для групп. В старых Linux-системах группы пользователей часто были общими, и пользователи назначались в одну и ту же группу, например, ‘users’ с GID 100. Это обусловило удобство управления, но вместе с тем несло определенные риски, связанные с безопасностью данных, так как файлы, созданные пользователями, могли по умолчанию быть доступны другим членам той же группы.
С течением времени системы безопасности улучшались, и возникла необходимость в индивидуальной конфиденциальности данных каждого пользователя. Это привело к созданию так называемой "схемы групп пользователей" (User Private Group scheme), где каждому пользователю назначается уникальная группа с GID, совпадающим с их UID. Основное преимущество этой модели заключается в том, что файлы, создаваемые пользователями, по умолчанию остаются доступными только для них, благодаря более строгим значениям umask (например, 077), что еще больше нивелирует риск непреднамеренного раскрытия данных.
Пример:
На практике, когда вы устанавливаете RHEL 7, 8 или 9, происходит автоматическое создание группы с именем, совпадающим с именем пользователя, и назначение ей уникального GID, начиная с 1000. Эта модель эффективна и соответствует современным стандартам безопасности. В то время как в некоторых старых дистрибутивах использовалась точка отсчета 500 для пользовательских GID, это было изменено, поскольку диапазон от 0 до 999 стал рассматриваться как системный.
Причина, по которой вы не можете назначить начальный пользовательский GID равным 100, заключается в программировании инсталлятора. Он разработан с ожиданием, что будет создана новая группа, и в соответствии с моделью User Private Group требует уникального идентификатора, что предотвращает возможность назначения GID, который уже существует.
Применение:
Если вам необходимо изменить поведение системы на стадии установки или в постинсталляционном процессе, вы можете достичь этого с помощью последующей ручной настройки. Используя утилиту usermod, можно изменить первичную группу пользователя после установки, например, на уже существующую группу ‘users’ с GID 100. Однако это требует внимательного расчета умаски (например, установить 077, чтобы избежать нежелательного доступа).
Кроме того, файл /etc/login.defs позволяет отключить автоматическое создание пользовательских групп, что можно сделать, если вы планируете управлять группами другим методом. Тем не менее, необходимо помнить о потенциальных рисках и управлять разрешениями на созданные файлы вручную.
Заключение:
В заключении, современная практика назначения уникальных групп пользователям исходя из их UID нацелена на повышение уровня безопасности и приватности. Несмотря на то, что это усложняет жизнь пользователям, привыкшим к традиционным подходам, данное изменение предлагает более гибкое и безопасное управление доступом. Что касается изменений по умолчанию через инсталлятор, они вызваны востребованностью обеспечения лучшей изоляции персональных данных в многопользовательской среде и более удобного управления разрешениями файлов.