Каковы известные UID? - PullRequest
4 голосов
/ 18 июня 2009

Согласно справочной странице useradd, UID ниже 1000 обычно резервируются для системных учетных записей.

Я разрабатываю сервис, который будет работать от своего собственного пользователя. Я знаю, что известные порты можно найти в /etc/services.

Есть ли место, где я могу узнать, какие там известные UID? Я хотел бы избежать сбоев с чужим UID.

Ответы [ 4 ]

7 голосов
/ 18 июня 2009

getpwent(3) перебирает базу данных паролей (обычно /etc/passwd, но не обязательно; например, система может находиться в домене NIS). Любой UID, известный системе, должен быть представлен там.

Для демонстрации следующий фрагмент оболочки и код на С должны вывести все известные UID в системе.

$ getent passwd | cut -d: -f3
#include <pwd.h>
#include <stdio.h>
int main() {
    struct passwd *pw;
    while ((pw = getpwent()))
        printf("%d\n", pw->pw_uid);
}

UID 0 всегда является корневым, и обычно UID 65534 - это nobody, но вы не должны рассчитывать ни на это, ни на что-либо еще. Какие UID используются, зависит от ОС, дистрибутива и даже системы - например, многие системные службы в Gentoo выделяют UID по мере их установки. Центральная база данных UID не используется.

Кроме того, /etc/login.defs определяет, что такое «системные идентификаторы». На моем рабочем столе он настроен так, что UID 100-999 рассматриваются как системные учетные записи, а UIDS 1000-60000 - это учетные записи пользователей, но это легко изменить.

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

4 голосов
/ 15 июня 2017

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

Концепция «хорошо известных UID» восходит к ранним временам Unix, до появления множества дистрибутивов и вариантов Unix. «Хорошо известные» идентификаторы UID считались для системных пользователей, таких как adm, daemon, lp, sync, operator, news, mail и т. Д., И были стандартными для всех различных систем во избежание столкновений uid. Эти пользователи по-прежнему присутствуют в современных Unix-подобных операционных системах.

Стандартизация uid в организации - ключ к избежанию этих проблем. Как отмечалось в комментарии выше, в наши дни любой выбранный вами uid, вероятно, будет использоваться «где-то», поэтому лучшее, чего может достичь системный администратор, - это обеспечение того, чтобы uid были стандартными во всех поддерживаемых ими системах, а затем выделение новый идентификатор приложения становится простым.

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

UNIX / Linux: анализ конфликтов UID / GID пользователей / групп

Если вы выполняете поиск в этом блоге по тегу 'uid', появляются другие релевантные записи, в том числе скрипт для автоматизации процесса стандартизации uid на нескольких хостах в Linux.

Это Определение идентификатора пользователя также является бесценным ресурсом.

Короткий ответ: на самом деле не имеет значения, какие uid вы используете, если они уникальны и стандартны во всей вашей организации, чтобы избежать столкновений.

0 голосов
/ 23 июня 2009

В Linux это настроено в /etc/login.defs. Иногда, когда я устанавливаю систему на основе Debian, я изменяю параметр «запуск uid» (я забыл его название, я сейчас не на Linux) с 1000 на 500 для совместимости с другими компьютерами Red Hat-y.

man login.defs должен предоставить вам всю необходимую информацию.

0 голосов
/ 18 июня 2009

Я не уверен, что такой список существует. Как насчет того, чтобы просто отметить, что UID используются через файл / etc / passwd , / etc / shadow и глобальный список пользователей NIS , отметив одни используются? Тогда используйте тот, который не!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...