Які небезпеки створення нормального користувача з UID <500?


14

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

Це не те, що я хочу зробити, а те, що я бачив і хочу знати, чому цього не слід робити. У цьому прикладі мова йде про RHEL5.


2
Системи, що походять з Debian, здаються, починають звичайні UID з 1000, а не 500.
Кіт Томпсон

Відповіді:


16

Я не вірю, що існує якийсь притаманний ризик. Це робиться просто для створення розділення між тим, що вважається системними обліковими записами, та обліковими записами користувачів. Практика використання цифр нижче 500, з мого досвіду, є Redhat-Ism, і насправді не більше того.

На Solaris я бачив, як користувачі присвоюють номери, починаючи з 100, лише через роки виявляють, що при об'єднанні двох менших систем департаментів разом викликає різного кошмару, оскільки в двох відділах було два користувачі, які мали той самий UID / Присвоєно GID

Це дійсно основний ризик / головний біль при призначенні UID. Оскільки UID - це те, що в кінцевому рахунку записується в inode для заданих користувачем файлів / каталогів, вам не хочеться, щоб у дорозі виконувати масові findпошуки файлів, які належать UID 1234, і потрібно змінити їх на 5678 .

Тож, подумавши про вибір UID, адміністратори можуть уникнути головного болю в дорозі.

Використання 500 і вище - це лише спроба Redhat (та інших Unixes) дати собі достатній буфер, щоб будь-які системні облікові записи, які, можливо, потрібно було б створити, не змішалися з 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команди.

Сторінка чоловіка Useradd

Якщо ви подивитеся на 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сторінці man, - це цей біт щодо створення облікових записів системи.

витяг

-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, які вже призначені користувачам системи.


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

@strugee - дякую, що я не хотів робити заяву надто широкою і змусив мене знову вкусити.
slm

2

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

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


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 для користувачів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.