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

редактировать

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

СОДЕРЖАНИЕ
  • 1 Атрибуты процесса
    • 1.1 Эффективный идентификатор пользователя
      • 1.1.1 Идентификатор пользователя файловой системы
    • 1.2 Сохраненный идентификатор пользователя
    • 1.3 Настоящий идентификатор пользователя
  • 2 Соглашения
    • 2.1 Тип
    • 2.2 Зарезервированные диапазоны
    • 2.3 Особые значения
  • 3 альтернативы
  • 4 См. Также
  • 5 ссылки
Атрибуты процесса

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

Действующий идентификатор пользователя

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

ID пользователя файловой системы

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

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

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

Сохраненный идентификатор пользователя ( suid) используется, когда программе, работающей с повышенными привилегиями, необходимо временно выполнить некоторую непривилегированную работу; изменение 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 Standard Base определяет основной спецификации, что значения UID в диапазоне от 0 до 99 должны быть статически выделенные системы, и не должны быть созданы с помощью приложений, в то время как UIDs от 100 до 499 должны быть зарезервированы для динамического распределения системных администраторов и после установки скрипты.

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

Systemd определяет ряд специальных диапазонов UID, включая

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

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

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

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

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

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

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

Особые ценности

  • 0: У суперпользователя обычно нулевой UID (0).
  • -1: значение (uid_t) -1зарезервировано POSIX для идентификации пропущенного аргумента.
  • 65535: этого значения по-прежнему избегают, потому что это было возвращаемое значение ошибки API, когда uid_t было 16 бит.
  • Никто: Исторически пользователю « none » был назначен UID -2несколькими операционными системами, хотя другие значения, такие как 2 15 -1 = 32 767, также используются, например, OpenBSD. Для совместимости между 16-битными и 32-битными UID многие дистрибутивы Linux теперь устанавливают его равным 2 16 -2 = 65 534; ядро Linux по умолчанию возвращает это значение, когда 32-битный UID не соответствует возвращаемому значению 16-битных системных вызовов. Fedora Linux никому не назначает последний UID диапазона, статически выделенного для использования системой (0–99): 99, и вместо этого вызывает 65534 nfsnobody.
Альтернативы

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

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

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

Смотрите также
использованная литература
Последняя правка сделана 2024-01-05 08:05:08
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте