Идентификатор пользователя

Unix-подобные операционные системы идентифицируют пользователя по значению, называемому идентификатором пользователя , который часто сокращается до идентификатора пользователя или UID . UID вместе с идентификатором группы (GID) и другими критериями управления доступом используется для определения того, к каким системным ресурсам может получить доступ пользователь. Файл паролей сопоставляет текстовые имена пользователей с UID. UID хранятся в inodes Unix , файловой системы запущенных процессах, tar- архивах и ныне устаревшей Network Information Service . В POSIX- совместимых средах оболочки команда id дает UID текущего пользователя, а также дополнительную информацию, такую как имя пользователя, основная группа пользователей и идентификатор группы (GID).

Атрибуты процесса

Стандарт POSIX ввел три разных поля UID в таблицу дескрипторов процессов, чтобы позволить привилегированным процессам динамически выполнять разные роли:

Эффективный идентификатор пользователя

Эффективный UID ( euid) процесса используется для большинства проверок доступа. Он также используется в качестве владельца файлов, созданных этим процессом. Эффективный GID ( egid) процесса также влияет на контроль доступа и может также влиять на создание файлов, в зависимости от семантики конкретной используемой реализации ядра и, возможно, используемых параметров монтирования . Согласно семантике BSD Unix , групповое владение вновь созданным файлом безоговорочно наследуется от группового владения каталогом, в котором он создан. Согласно семантике AT&T UNIX System V (также принятой в вариантах Linux ), вновь созданному файлу обычно присваивается групповое право собственности, указанное в egid процесса, создающего файл. Большинство файловых систем реализуют метод выбора, следует ли использовать семантику BSD или AT&T в отношении группового владения вновь созданным файлом; Семантика BSD выбирается для конкретных каталогов, когда установлено разрешение S_ISGID (s-gid). ^[1]

Идентификатор пользователя файловой системы

В Linux также есть идентификатор пользователя файловой системы ( fsuid), который используется явно для контроля доступа к файловой системе. Это соответствует euid если явно не указано иное. Это может быть root, только если идентификатор пользователя ruid, suid, или euid является корнем. Всякий раз, когда euid изменено, изменение распространяется на fsuid.

Цель fsuid заключается в том, чтобы позволить программам (например, серверу NFS ) ограничивать себя правами файловой системы некоторых заданных uid не давая этого uid разрешение посылать им сигналы. Начиная с ядра 2.0, существование fsuid больше не требуется, поскольку Linux придерживается правил SUSv3 для отправки сигналов, но fsuid остается по соображениям совместимости. ^[2]

Сохраненный идентификатор пользователя

Сохраненный идентификатор пользователя используется, когда программе, работающей с повышенными привилегиями, необходимо временно выполнить непривилегированную работу; изменение euid из привилегированного значения (обычно 0) к некоторому непривилегированному значению (любому, кроме привилегированного значения), приводит к тому, что привилегированное значение сохраняется в suid. Позже программа euid можно вернуть значение, сохраненное в suid, чтобы можно было восстановить повышенные привилегии; непривилегированный процесс может установить свой euid одному из трех значений: значению ruid, значение suid, или значение euid.

Реальный идентификатор пользователя

Настоящий UID ( ruid) и реальный GID ( rgid) идентифицируют реального владельца процесса и влияют на разрешения на отправку сигналов. Процесс без привилегий суперпользователя может сигнализировать другому процессу только в том случае, если отправитель ruid или euid соответствует получателю ruid или suid. Поскольку дочерний процесс наследует свои учетные данные от своего родителя, дочерний и родительский процессы могут сигнализировать друг другу.

Конвенции

Тип

POSIX требует, чтобы UID был целочисленным типом. Большинство Unix-подобных операционных систем представляют UID как целое число без знака. Размер значений UID различается в разных системах; некоторые ОС UNIX ^{[ который? ]} используются 15-битные значения, допускающие значения до 32767 ^{[ нужна ссылка ]}, в то время как другие, такие как Linux (до версии 2.4), поддерживали 16-битные UID, что позволяло использовать 65536 уникальных идентификаторов. Большинство современных Unix-подобных систем (например, Solaris 2.0 в 1990 году, Linux 2.4 в 2001 году) перешли на 32-битные UID, что позволяет использовать 4 294 967 296 (2 ³²) уникальные идентификаторы.

Зарезервированные диапазоны

Стандартная базовая спецификация Linux определяет, что значения UID в диапазоне от 0 до 99 должны статически выделяться системой и не должны создаваться приложениями, а UID от 100 до 499 должны быть зарезервированы для динамического выделения системными администраторами и после установки. сценарии. ^[3]

Debian Linux не только резервирует диапазон 100–999 для динамически выделяемых системных пользователей и групп, но также централизованно и статически выделяет пользователей и группы в диапазоне 60000–64999, а также резервирует диапазон 65000–65533. ^[4]

Systemd определяет ряд специальных диапазонов UID, в том числе ^[5]

60001-60513: UID домашних каталогов, управляемых systemd-homed.
61184-65519 (0xef00-0xffef): UID для динамических пользователей.

Во FreeBSD портировщики, которым нужен UID для своего пакета, могут выбрать свободный идентификатор в диапазоне от 50 до 999, а затем зарегистрировать статическое распределение. ^[6]^[7]

Некоторые системы POSIX выделяют UID для новых пользователей, начиная с 500 ( macOS , Red Hat Enterprise Linux до версии 6), другие начинаются с 1000 (Red Hat Enterprise Linux начиная с версии 7, ^[8] openSUSE , Дебиан ^[4]). Во многих системах Linux эти диапазоны указаны в /etc/login.defs, для useradd и подобные инструменты.

Центральное распределение UID в корпоративных сетях (например, через серверы LDAP и NFS ) может ограничиваться использованием только номеров UID, значительно превышающих 1000 и выходящих за пределы диапазона 60000–65535, чтобы избежать потенциальных конфликтов с UID, локально распределенными на клиентских компьютерах. Когда новые пользователи создаются локально, локальная система должна проверять и избегать конфликтов с UID, уже существующими на NSS. ^[9]

Виртуализация на уровне ОС может переназначать идентификаторы пользователей, например, с использованием пространств имен Linux , и поэтому необходимо выделять диапазоны, в которые сопоставляются переназначенные UID и GID:

snapd сопоставляет UID и GID в диапазоне 524288-589823 (0x80000-0x8ffff)
systemd-nspawn автоматически распределяет диапазоны UID для каждого контейнера, используя диапазон 524288-1879048191 (0x80000-0x6fffffff) ^[5]

Авторы systemd рекомендуют системам виртуализации на уровне ОС выделять 65536 (2 ¹⁶) UID для каждого контейнера и сопоставьте их, добавив целое число, кратное 2. ¹⁶. ^[5]

Особые значения

0: UID суперпользователя обычно равен нулю (0). ^[10]
−1: значение (uid_t) -1 зарезервирован POSIX для идентификации пропущенного аргумента. ^[11]
65535: Это значение по-прежнему не используется, поскольку оно было возвращаемым значением ошибки API, когда uid_t составлял 16 бит.
Никто: исторически пользователю « никто » присваивался UID. -2 несколькими операционными системами, хотя другие значения, например 2 ¹⁵−1 = 32 767 также используются, например, в OpenBSD . ^[12] Для совместимости между 16-битными и 32-битными UID во многих дистрибутивах Linux теперь установлено значение 2. ¹⁶−2 = 65 534; ядро Linux по умолчанию возвращает это значение, когда 32-битный UID не соответствует возвращаемому значению 16-битных системных вызовов. ^[13] Fedora Linux никому не присваивает последний UID диапазона, статически выделенного для использования системой (0–99): 99, и вместо этого вызывает 65534. nfsnobody.

Альтернативы

NFSv4 был призван помочь избежать коллизий числовых идентификаторов путем идентификации пользователей (и групп) в пакетах протокола с использованием текстовых имен «пользователь@домен», а не целых чисел. Однако, пока ядра операционной системы и локальные файловые системы продолжают использовать целочисленные идентификаторы пользователей, это происходит за счет дополнительных шагов трансляции (с использованием процессов демона idmap), которые могут привести к появлению дополнительных точек сбоя, если локальные механизмы сопоставления UID или базы данных получат ошибку. настроены неправильно, потеряны или не синхронизированы. Часть имени пользователя «@domain» может использоваться для указания того, какой орган власти выделил конкретное имя, например, в форме

имя Kerberos области
доменное Active Directory имя
имя поставщика операционной системы (для распределения по конкретному дистрибутиву)
имя компьютера (для распределения по конкретному устройству)

Но на практике многие существующие реализации позволяют устанавливать для домена NFSv4 только фиксированное значение, что делает его бесполезным.

См. также

Ссылки

^ chmod(1) – Solaris 11.4 по пользовательским командам Справочное руководство
^ Керриск, Майкл. Программный интерфейс Linux . Без крахмала Пресс, 2010, с. 171.
^ «9.3. Диапазоны UID» . Refspecs.linuxfoundation.org . Проверено 24 сентября 2016 г.
^ Перейти обратно: ^а ^б «Руководство по политике Debian – Раздел 9.2.2: Классы UID и GID» . Debian.org . 18 июля 2019 г. Проверено 26 июля 2019 г.
^ Перейти обратно: ^а ^б ^с «Пользователи, группы, UID и GID в системах systemd» . Гитхаб . Проверено 26 сентября 2020 г.
^ «Справочник портировщика FreeBSD» . Freebsd.org . Проверено 24 сентября 2016 г.
^ «Глава 6. Особенности» .
^ «Изменения в системе RHEL7» . Certdepot.net . 17 января 2016 г. Проверено 22 марта 2017 г.
^ https://systemd.io/UIDS-GIDS/ «для обоих диапазонов распределения: когда происходит выделение UID, NSS сначала проверяется на предмет коллизий, и если запись найдена, выбирается другой UID»
^ «Получить» . Pubs.opengroup.org . Проверено 24 сентября 2016 г.
^ «Чоун» . Pubs.opengroup.org . Проверено 24 сентября 2016 г.
^ «Отчет о проблеме NetBSD № 6594: учетные данные «никто» по умолчанию (32767:9999) не соответствуют учетным данным mountd по умолчанию (-2:-2)» . GnaNFSv4ts.netbsd.org . Проверено 24 сентября 2016 г.
^ «Пространства имен в работе, часть 5: Пользовательские пространства имен» . Lwn.net . Проверено 24 сентября 2016 г.

[1] chmod(1) – Solaris 11.4 по пользовательским командам Справочное руководство

[Kerrisk-2] Керриск, Майкл. Программный интерфейс Linux . Без крахмала Пресс, 2010, с. 171.

[3] «9.3. Диапазоны UID» . Refspecs.linuxfoundation.org . Проверено 24 сентября 2016 г.

[debian-4] Перейти обратно: ^а ^б «Руководство по политике Debian – Раздел 9.2.2: Классы UID и GID» . Debian.org . 18 июля 2019 г. Проверено 26 июля 2019 г.

[systemd-5] Перейти обратно: ^а ^б ^с «Пользователи, группы, UID и GID в системах systemd» . Гитхаб . Проверено 26 сентября 2020 г.

[6] «Справочник портировщика FreeBSD» . Freebsd.org . Проверено 24 сентября 2016 г.

[7] «Глава 6. Особенности» .

[8] «Изменения в системе RHEL7» . Certdepot.net . 17 января 2016 г. Проверено 22 марта 2017 г.

[9] ttps://systemd.io/UIDS-GIDS/ «для обоих диапазонов распределения: когда происходит выделение UID, NSS сначала проверяется на предмет коллизий, и если запись найдена, выбирается другой UID»

[10] «Получить» . Pubs.opengroup.org . Проверено 24 сентября 2016 г.

[11] «Чоун» . Pubs.opengroup.org . Проверено 24 сентября 2016 г.

[12] «Отчет о проблеме NetBSD № 6594: учетные данные «никто» по умолчанию (32767:9999) не соответствуют учетным данным mountd по умолчанию (-2:-2)» . GnaNFSv4ts.netbsd.org . Проверено 24 сентября 2016 г.

[13] «Пространства имен в работе, часть 5: Пользовательские пространства имен» . Lwn.net . Проверено 24 сентября 2016 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]