Вопрос или проблема
идентификатор группы (gid) 100 — это users в /etc/group
когда я устанавливаю RHEL 7, 8 или 9, она не позволяет мне создать этого одного первоначального пользователя с gid, равным 100 (которая является users), графический интерфейс возвращается к 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’ – но без того, чтобы все другие файлы автоматически становились доступными для членов группы пользователей по умолчанию.
Короче говоря, идея состоит в том, чтобы файлы пользователей были по умолчанию rwx rwx ---, и персональные группы пользователей позволяют таким файлам по-прежнему оставаться частными по умолчанию.
(Это, кажется, предшествовало внедрению POSIX ACL, где “умолчательный ACL” g::rwx могли быть установлены для каждого каталога вместо необходимости в глобальной umask.)
Таким образом, поскольку установщик запрограммирован безусловно создавать группу, он ожидает, что ему дадут идентификатор группы, который еще не существует, и поскольку он, вероятно, был написан с учетом модели «usergroup», устанавливает ожидаемый диапазон GID соответствующим стандартному диапазону UID (0-999, являющийся “системным” диапазоном UID). Ранее диапазон в Fedora/RedHat начинался с 500, и в графическом интерфейсе Anaconda ограничения ввода были установлены соответственно.
Ручное изменение вашего основного GID на users(100) через usermod (и отключение автоматического создания групп пользователей через /etc/login.defs для будущих вызовов useradd) не должно вызвать никаких проблем – по крайней мере, если тот же самый login.defs также указывает достаточно строгий umask (077 или 022, если вы хотите традиционный, в отличие от 007). Кроме файлов, я не могу придумать никаких других ресурсов, которые могли бы дать нежелательный доступ в результате нахождения в общей основной группе.
.
Ответ или решение
История и Конвенция использования GID 100 группы users
Теория
Группа с gid=100, именуемая users, изначально использовалась в UNIX-системах как группа по умолчанию для обычных пользователей. Такие группы исторически служили для управления доступом и предоставления стандартных разрешений. Однако в современных дистрибутивах Linux, таких как RHEL 7, 8 и 9, присутствует концепция «user groups», в которой для каждого пользователя, создаваемого в системе, также создается одноименная группа, что облегчает управление доступом к файлам и ресурсам.
Идея в том, чтобы каждый пользователь имел свою личную группу, так как это позволяет по умолчанию присваивать файлы режима rwx rwx ---, сохраняя их приватными, пока в системе используется умаска 027 или 077. Это решение позволяет, с одной стороны, легко предоставлять доступ к файлам для конкретных групп, а, с другой, защищать файлы пользователей от того, чтобы они становились общедоступными.
Обеспечение данной конфигурации настраивается в файле /etc/login.defs, где можно указать создание новых групп по умолчанию.
Пример
При установке RHEL у вас возникает вопрос, почему невозможно установить gid=100 для нового пользователя. Причина кроется в работе установщика, которого настроили для создания новой группы с уникальным gid, начиная с 1000. Из-за исторических причин и концепции индивидуальных групп пользователей, это решение применено для минимизации конфликтов и улучшения безопасности.
Система управляет учетными записями, где каждый пользователь изначально добавляется в группу с таким же именем, как и его имя пользователя. Например, если вы создаете пользователя john, то одновременно создается группа john с уникальным gid.
Применение
Чтобы изменить по умолчанию назначаемые gid, вы можете вручную настроить пользователя через команду usermod, изменяя его первичную группу на users с gid=100. Это возможно без значительных последствий, если изменить умаску для новых файлов на более ограничивающую, например, 077. В файле /etc/login.defs можно отключить автоматическое создание одноименных групп. Однако, стоит учесть, что использование общей группы приводит к избыточной открытости доступа, если не следить за умаской, и это может вызвать проблемы с правами доступа к файлам.
Исторически, группы с низкими gid (такие как 100 и менее) использовались для системных процессов и имеют стандартные права. Таким образом, введение индивидуальных групп уменьшает риски, связанные с открытими правами. Современные POSIX ACL могут частично устранить такие потребности, но концепция индивидуальных групп остается популярной благодаря своей простоте и эффективности.
Подводя итог, изменение gid на 100 возможно, но требует внимания к умаске, настройке дефолтных значений доступа и безопасности данных в системе. Это решение имеет смысл, если вы администрируете множество пользователей и хотите централизовать контроль над доступом к файлам, но требует взвешенного подхода к конфигурации безопасности. Truncated feedback of approximately 4400+ characters is converted to completion format in line 2 and completion ends on line 37.