Кратко

  • Capability Amoeba состоял из 48-битного порта сервера, 24-битного номера объекта, 8-битной карты прав и 48-битного поля проверки. Пользовательский процесс мог хранить и передавать эту несущую полномочия ссылку.
  • Принятие токена сервером подтверждало соответствие правилам проверки и наличие нужного права. Оно не подтверждало имя предъявителя, его мандат и цель, завершение последующего действия или долговечность результата.

Поле, которого в формате не было

Процесс в Amoeba предъявлял серверу компактную битовую строку вместе с запросом операции. Порт направлял запрос службе. Номер объекта выбирал ресурс в пространстве этой службы. Биты прав ограничивали доступные предъявителю действия. Поле проверки помогало серверу заметить подделку либо попытку расширить полномочия.

Поля «человек» в формате не существовало.

Это не недостающая часть будущей системы идентификации, а свойство распределённой архитектуры. Пользовательские процессы могли сами хранить, копировать и пересылать capabilities. Полномочие перемещалось вместе со ссылкой, а сервер проверял ссылку и операцию, не биографию предъявителя. Системе не требовалось вести в центральном компоненте полный перечень владельцев каждого токена.

Механизм точно отвечал на узкий вопрос: может ли предъявитель этой действительной ссылки запросить данную операцию над данным объектом у данного сервера? Он не отвечал, какое место предъявитель занимает в организации, почему действует сейчас, намеревался ли согласующий разрешить именно это действие и произошёл ли ожидаемый эффект за границей сервера.

Четыре поля и четыре ограниченные функции

Статья 1986 года Using Sparse Capabilities in a Distributed Operating System задаёт формат без двусмысленности: 48 бит порта сервера, 24 бита номера объекта, 8 бит прав и 48 бит поля проверки. Итого 128 бит.

Порт и номер объекта выполняют разные задачи. Порт обозначает конечную точку службы в RPC-модели Amoeba. Номер получает смысл внутри сервера; отчёт 1991 года сравнивает номер объекта файлового сервера с номером inode. Ядро может по порту найти сервер, но остальную часть capability передаёт ему. Тем самым поиск службы отделён от интерпретации объекта.

Байт прав — не универсальный перечень восьми команд. Это битовая карта, значение которой задаёт интерфейс сервера. Для файла биты могут означать чтение, запись и удаление, а для объекта процесса — запуск, остановку и проверку состояния. Одинаковая ширина поля не делает операции равнозначными. Она лишь даёт каждой службе небольшую явную поверхность для описания полномочий предъявителя.

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

Поэтому слова «неподделываемая ссылка» нуждаются в оговорках. Историческая конструкция должна была сделать изготовление токена практически невозможным при заданных предпосылках. Она не превращает 48-битное поле в вечную гарантию против современных вычислительных ресурсов, не защищает от применения скопированного законного токена и не шифрует capability в небезопасном канале. Сам отчёт 1991 года отмечает, что для предотвращения случайного раскрытия в небезопасной среде может понадобиться криптография.

Ослабление полномочий было вычитанием

Capability владельца изначально имел все включённые биты прав. Чтобы передать другому процессу меньше полномочий, держатель мог запросить у сервера ограничение с помощью маски. Сервер проверял исходный токен, пересекал существующие права с маской и создавал для того же объекта новую capability с меньшими правами и производным полем проверки. Пример std_restrict в руководстве выражает суть одной строкой: rights &= mask.

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

При этом нельзя сводить варианты из разных публикаций к одному алгоритму. Работа 1986 года рассматривает несколько способов защиты прав: сочетание сохранённого случайного значения и прав через одностороннюю функцию; выпуск ограниченного токена сервером; локальное ослабление с семейством коммутативных односторонних функций. Отчёт 1991 года описывает серверный вариант, использовавшийся в изложенной там версии Amoeba. Это связанные эксперименты, а не одна неразличимая реализация.

Граница соавторства столь же важна. Авторы Using Sparse Capabilities — Andrew S. Tanenbaum, Sape J. Mullender и Robbert van Renesse. Отчёт The Amoeba Distributed Operating System—A Status Report написали Таненбаум, M. Frans Kaashoek, van Renesse и Henri E. Bal. Таненбаум служит уместной персональной точкой входа, но не поводом приписывать коллективную систему одному человеку.

Обладание давало право, но не удостоверяло личность

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

Успешная проверка означает, что предъявленный токен действителен для названного объекта и видимых прав при текущем секрете сервера. Из неё нельзя узнать, получил ли процесс токен непосредственно от создателя, нашёл через каталог, принял от другого процесса или скопировал из места, где тот не должен был оказаться. Без дополнительного механизма нет связи с сотрудником, договорной ролью или юридическим лицом.

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

У отзыва такая же ограниченная форма. Изменение хранимого сервером случайного значения может сделать недействительными все прежние capabilities объекта. Это мощный сброс на уровне объекта, но не выборочное знание о каждой копии, не ретроспективная атрибуция прежнего использования и не доказательство удаления утёкшей строки из всех процессов и архивов.

Ответ останавливается на смысловой границе сервера

Предположим, действительная capability разрешает операцию, и сервер возвращает успех. Самое сильное обоснованное утверждение определяется семантикой операции: сервер принял и выполнил изменение согласно своей реализации. Из этого автоматически не следует, что изменение пережило сбой, дошло до всех реплик, привело в движение физическое устройство, завершило внешний платёж или соответствовало корпоративной процедуре изменений.

Это разные поверхности контроля. Сохранность относится к хранению и восстановлению. Физическое или сетевое действие — к подсистеме, которая его выполняет и наблюдает. Человеческое одобрение — к организации, задающей мандат. Компактный токен способен открыть одну операцию, не становясь универсальной квитанцией обо всём, что должно было произойти после неё.

В этом и состоит долговечная ценность примера Amoeba: он ясно соединяет именование и защиту, а затем останавливается. Граница — не недостаток, который надо скрыть, а условие понятности механизма.

Источники