Unix-подобные операционные системы идентифицируют пользователя по значению, называемому идентификатором пользователя , который часто сокращается до идентификатора пользователя или UID . UID вместе с идентификатором группы (GID) и другими критериями управления доступом используется для определения того, к каким системным ресурсам может получить доступ пользователь. Файл паролей сопоставляет текстовые имена пользователей с UID. UID хранятся в inodes файловой системы Unix , запущенных процессах, tar- архивах и ныне устаревшей Network Information Service . В средах, совместимых с POSIX , команда оболочки предоставляет UID текущего пользователя, а также дополнительную информацию, такую как имя пользователя, основная группа пользователей и идентификатор группы (GID). id
Стандарт 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, если явно не указано иное. Это может быть идентификатор пользователя rootruid , только если , suid, или euidroot. Всякий раз, когда 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 32 ) уникальных идентификаторов.
Стандартная базовая спецификация Linux определяет, что значения UID в диапазоне от 0 до 99 должны статически выделяться системой и не должны создаваться приложениями, а UID от 100 до 499 должны быть зарезервированы для динамического выделения системными администраторами и после установки. сценарии. [3]
Debian Linux не только резервирует диапазон 100–999 для динамически выделяемых системных пользователей и групп, но также централизованно и статически выделяет пользователей и группы в диапазоне 60000–64999, а также резервирует диапазон 65000–65533. [4]
Systemd определяет ряд специальных диапазонов UID, включая [5]
В FreeBSD портеры, которым нужен UID для своего пакета, могут выбрать свободный идентификатор в диапазоне от 50 до 999, а затем зарегистрировать статическое распределение. [6] [7]
Некоторые системы POSIX выделяют UID для новых пользователей, начиная с 500 ( macOS , Red Hat Enterprise Linux до версии 6), другие начинаются с 1000 (Red Hat Enterprise Linux, начиная с версии 7, [8] openSUSE , Debian [4] ). Во многих системах Linux эти диапазоны указаны в /etc/login.defs, for useraddи подобных инструментах.
Центральное распределение UID в корпоративных сетях (например, через серверы LDAP и NFS ) может ограничиваться использованием только номеров UID, значительно превышающих 1000 и выходящих за пределы диапазона 60000–65535, чтобы избежать потенциальных конфликтов с UID, локально распределенными на клиентских компьютерах. Когда новые пользователи создаются локально, локальная система должна проверять и избегать конфликтов с UID, уже существующими в NSS [9] .
Виртуализация на уровне ОС может переназначать идентификаторы пользователей, например, с использованием пространств имен Linux , и поэтому необходимо выделять диапазоны, в которые сопоставляются переназначенные UID и GID:
Авторы systemd рекомендуют системам виртуализации на уровне ОС выделять 65536 (2 16 ) UID для каждого контейнера и сопоставлять их, добавляя целое число, кратное 2 16 . [5]
(uid_t) -1зарезервировано POSIX для идентификации пропущенного аргумента. [11]-2в нескольких операционных системах, хотя другие значения, такие как 2 15 −1 = 32 767, также используются, например, в OpenBSD . [12] Для совместимости между 16-битными и 32-битными UID во многих дистрибутивах Linux теперь установлено значение 2 16 −2 = 65 534; ядро Linux по умолчанию возвращает это значение, когда 32-битный UID не соответствует возвращаемому значению 16-битных системных вызовов. [13] Fedora Linux никому не присваивает последний UID диапазона, статически выделенного для использования системой (0–99): 99, и вместо этого вызывает 65534 nfsnobody.NFSv4 был призван помочь избежать коллизий числовых идентификаторов путем идентификации пользователей (и групп) в пакетах протокола с использованием текстовых имен «пользователь@домен», а не целых чисел. Однако до тех пор, пока ядра операционной системы и локальные файловые системы продолжают использовать целочисленные идентификаторы пользователей, это происходит за счет дополнительных шагов трансляции (с использованием процессов демона idmap), которые могут привести к появлению дополнительных точек сбоя, если локальные механизмы сопоставления UID или базы данных получат ошибку. настроены неправильно, потеряны или не синхронизированы. Часть имени пользователя «@domain» может использоваться для указания того, какой орган власти выделил конкретное имя, например, в форме
Но на практике многие существующие реализации позволяют устанавливать только фиксированное значение домена NFSv4, что делает его бесполезным.