Каковы опасности создания обычного пользователя с UID <500?

Каковы опасности создания обычного пользователя с UID <500? Если предположить, что UID не являются дубликатами существующих UID, что может пойти не так?

Это не то, что я хочу сделать, а то, что я видел и хочу знать, почему этого не следует делать. В этом примере это на RHEL5.

Я не верю, что существует какой-то неотъемлемый риск, это то, что делается просто для того, чтобы отделить то, что считается системными учетными записями и учетными записями пользователей. Практика использования чисел ниже 500, по моему опыту, является редхатизмом, и на самом деле не более того.

В Solaris я видел пользователей, которым также назначали номера, начинающиеся с 100, только спустя годы обнаружил, что при объединении систем из двух небольших отделов возникает своего рода кошмар, поскольку в двух отделах было несколько пользователей с одинаковым UID / GID назначен.

Это действительно основной риск / головная боль при назначении UID. Поскольку UID - это то, что в конечном итоге записывается в inode для заданных пользователем файлов / каталогов, вам не нужно, чтобы вам приходилось выполнять массовый findпоиск файлов, принадлежащих UID 1234, и менять их на 5678 ,

Поэтому, задумавшись о выборе UID, администраторы могут избежать головной боли в будущем.

Использование 500 и выше - это всего лишь попытка Redhat (и других Unix-систем) выделить себе достаточно буфера, чтобы любые системные учетные записи, которые могут понадобиться для создания, не смешивались с UID, назначенными пользователям.

/etc/login.defs

Кстати, число 500 определяется этим параметром в файле конфигурации /etc/login.defs.

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN           500
UID_MAX         60000

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN           500
GID_MAX         60000

Вы можете изменить это на что угодно, если хотите изменить поведение по умолчанию с помощью команд useradd/ adduser.

Manradd man page

Если вы посмотрите на useraddстраницу руководства, вы заметите эту часть, в которой обсуждается значение по умолчанию для GID, но этот комментарий также применим и к UID:

выдержка

-g, --gid GROUP
    The group name or number of the user´s initial login group. The group name 
    must exist. A group number must refer to an already existing group.

    If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB 
    variable in /etc/login.defs. If this variable is set to yes 
    (or -U/--user-group is specified on the command line), a group will be 
    created for the user, with the same name as her loginname. If the variable 
    is set to no (or -N/--no-user-group is specified on the command line), 
    useradd will set the primary group of the new user to the value specified by 
    the GROUP variable in /etc/default/useradd, or 100 by default.

Системные учетные записи

Еще одна вещь, которую стоит обратить внимание на useraddстранице руководства, - это бит при создании системного аккаунта.

выдержка

-r, --system
    Create a system account.

    System users will be created with no aging information in /etc/shadow, 
    and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX 
    range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their 
    GID counterparts for the creation of groups).

    Note that useradd will not create a home directory for such an user, 
    regardless of the default setting in /etc/login.defs (CREATE_HOME). You 
    have to specify the -m options if you want a home directory for a system 
    account to be created.

Именно этот метод ( useradd -r ...) часто используется сценариями, которые включаются в различные менеджеры пакетов, такие как RPM, при установке пакета. Создание сценариев таким образом позволяет системе автоматически выбирать следующий доступный UID / GID в данной системе без риска наступления на UID / GID, уже назначенные пользователям системы.

С точки зрения ядра есть только один специальный пользователь: UID 0. Разделение диапазонов UID по административным причинам упрощает вашу жизнь. Общие диапазоны: поставщик, системный, локальный, глобальный.

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

В этом нет никакой опасности. Если вы создадите пользователя с UID 499, у него не будет лишних привилегий. Причина, по которой предлагается не делать этого, заключается просто в том, что UID обычно зарезервированы для пользователей системы. Проблема, с которой можно столкнуться при создании такого UID, заключается в том, что некоторая системная служба ожидает, что UID будет доступен. Это похоже на создание нового сервиса, работающего на хорошо известном порту - с ним проблем нет, но это не очень хорошая практика и может вызвать проблемы в дальнейшем, когда вы настраиваете sshd, ftpd и т. Д.

Тем не менее, я видел много систем, где пользователи создавались с UID <500 без проблем. Однако по мере роста базы пользователей и появления тысяч пользователей может быть затруднительно проводить различие между учетными записями пользователей и системными учетными записями. Следуя правилу отсутствия UID <500, это очень просто. Так что это хороший способ организовать аккаунты.

Там нет реальной опасности. Ядро не заботится о значениях идентификаторов пользователей, кроме 0. Большинство инструментов администрирования тоже не заботятся - очень мало частей системы имеют различие между пользователями системы и людьми.

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

В некоторых дистрибутивах резервируется диапазон 1–499 (Red Hat и родственники) или 1–999 (Debian и родственники) для пользователей системы, включая пользователей, выделяемых при установке пакета, содержащего системную службу, для которой требуется выделенный пользователь. Соглашение Debian заключается в том, что диапазон 1–99 является статически распределенным (поэтому создание пользователя-пользователя в этом диапазоне - очень плохая идея, так как это может конфликтовать с пользователем системы), в то время как диапазон 100–999 динамически выделяется (таким образом, создавая пользователя-пользователя). в этом диапазоне безвреден, так как любой новый пользователь системы выберет бесплатный идентификатор пользователя).

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

Главная опасность для изолированной машины состоит в том, что вы можете запутать своих коллег-системных администраторов. Для машины в сети, где идентификаторы пользователей являются общими, вы можете столкнуться с конфликтами с другими машинами, где эти пользователи имеют тот же идентификатор пользователя, что и системный пользователь. В сетях с общими идентификаторами пользователей лучше всего придерживаться диапазона 1000–65533 или даже 10000–65533 для пользователей.