Что опасности создать обычный пользователь с UID <500?

Могло быть много вещей. Возможно, одна из программ, которые Вы запускаете, иногда и кратко использует много RAM. Если это - действительно недели на оси X, необходимо выбрать в намного более высоком разрешении (например, однажды в минуту или даже второй) для получения большей информации о том, что продолжается, который заставляет кэш быть отброшенным. ps и top вывод (включая среднее число загрузки) в течение того времени был бы полезен также.

14
15.11.2013, 19:20
5 ответов

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

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

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

Таким образом путем помещения некоторой мысли в выбор UIDs, администраторы могут избежать головной боли в будущем.

Использование 500 и выше является просто попыткой Redhat (и другой Unixes), чтобы дать себе достаточно буфера, что любые системные учетные записи, которые, возможно, должны были бы быть созданы, не будут смешаны с UIDs, которые присвоены пользователям.

/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 команды.

Страница справочника Useradd

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

выборка

-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 ...) это часто - времена, используемые путем сценариев, это включено в различные кормушки пакета, такие как об/мин, когда пакет устанавливается. При сценариях его этот путь позволяет системе автоматически выбирать следующий доступный UID/GID в данной системе без риска продвижения на UIDs/GIDs, уже присвоенный пользователям системы.

16
27.01.2020, 19:51
  • 1
    FWIW, я думаю, что это - общий GNU/Linux-ism, не только изм Red Hat. Я видел это во всех системах, которые я использую, и я никогда не использовал Red Hat. –  strugee 15.11.2013, 20:19
  • 2
    @strugee - благодарит, я не хотел делать оператор к чрезмерно широкому и иметь его, возвращаются, чтобы укусить меня. –  slm♦ 15.11.2013, 21:31

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

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

2
27.01.2020, 19:51

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

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

1
27.01.2020, 19:51

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

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

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

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

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

1
27.01.2020, 19:51

В RHEL, когда вы выходите из системы, systemd убивает все ваши процессы, которые вы оставили запущенными в системе. Он также удаляет все сегменты общей памяти, созданные вами во время сеанса. Если вы не системный пользователь (, ваш uid < 1000 ).

Есть большая разница, когда вы запускаете базу данных Oracle как системный пользователь, а не как -не системный пользователь.

0
01.10.2020, 11:46

Теги

Похожие вопросы