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

14

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

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

Джефф
источник
2
Производные от Debian системы, похоже, запускают обычные UID с 1000, а не с 500.
Кит Томпсон

Ответы:

16

Я не верю, что существует какой-то неотъемлемый риск, это то, что делается просто для того, чтобы отделить то, что считается системными учетными записями и учетными записями пользователей. Практика использования чисел ниже 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, уже назначенные пользователям системы.

SLM
источник
1
FWIW, я думаю, что это общий GNU / Linux-изм, а не просто Red Hat-ism. Я видел это на всех системах, которые я использую, и я никогда не использовал Red Hat.
стружка
@strugee - спасибо, я не хотел делать излишне широкое заявление и заставить его вернуться, чтобы укусить меня.
SLM
2

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

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

hildred
источник
1

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

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

Франц Кафка
источник
1

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

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

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

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

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

Жиль "ТАК - перестань быть злым"
источник