Unix-подобные операционные системы идентифицируют пользователя по значению, называемому идентификатором пользователя , часто сокращаемому до идентификатора пользователя или UID . UID, наряду с идентификатором группы (GID) и другими критериями контроля доступа, используется для определения того, к каким системным ресурсам пользователь может получить доступ. Файл паролей сопоставляет текстовые имена пользователей с UID. UID хранятся в inode файловой системы Unix , запущенных процессах, архивах tar и ныне устаревшей сетевой информационной службе . В средах, совместимых с 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, или euidявляется root. Всякий раз, когда 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 [ which? ] использовали 15-битные значения, допуская значения до 32767 [ необходима цитата ] , в то время как другие, такие как Linux (до версии 2.4), поддерживали 16-битные UID, делая возможными 65536 уникальных ID. Большинство современных систем типа Unix (например, Solaris 2.0 в 1990 году, Linux 2.4 в 2001 году) перешли на 32-битные UID, допуская 4 294 967 296 (2 32 ) уникальных ID.
В спецификации Linux Standard Base Core указано, что значения 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, для 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), nobody: 99 и вместо этого вызывает 65534 nfsnobody.NFSv4 был призван помочь избежать коллизий числовых идентификаторов, идентифицируя пользователей (и группы) в пакетах протокола с помощью текстовых имен «user@domain», а не целых чисел. Однако, пока ядра операционных систем и локальные файловые системы продолжают использовать целочисленные идентификаторы пользователей, это происходит за счет дополнительных этапов трансляции (с использованием демон-процессов idmap), которые могут вносить дополнительные точки отказа, если локальные механизмы сопоставления UID или базы данных будут настроены неправильно, потеряны или не синхронизированы. Часть «@domain» имени пользователя может использоваться для указания того, какой орган выделил конкретное имя, например, в форме
Однако на практике многие существующие реализации позволяют устанавливать для домена NFSv4 только фиксированное значение, что делает его бесполезным.