Кратко

  • RFC 3341 выбирал самую точную запись для owner и actor; после удаления точной записи более общий шаблон мог сохранить часть разрешений.
  • Полный запрет обеспечивала оставленная точная запись all:none; удаление строки, ответ сервиса, уведомление владельца, эффективное решение и enforcement были разными квитанциями.

В примере точная запись разрешает конкретному actor передачу данных, подписку на присутствие и наблюдение. Другая запись разрешает всем субъектам того же домена только передачу данных. После удаления первой субъект теряет два права, но сохраняет третье через широкое правило.

Запись действительно удалена. Операция не сломалась. Изменился набор претендентов, и прежнее фоновое правило стало лучшим совпадением. Если нужно запретить всё, спецификация оставляет точную запись и меняет её действия на all:none. Точный отрицательный ответ продолжает побеждать шаблонный grant.

Право как результат выбора

Запись содержала owner, actor, действия и время lastUpdate, назначенное сервисом. Owner указывал конечную точку или подадрес, actor — сущность или группу, а действие соединяло сервис и операцию. Например, core:data использовалось при проверке передачи данных к owner через релейную сеть.

В локальной и доменной частях actor допускались ограниченные шаблоны. Поэтому одной конкретной сущности могли соответствовать несколько записей. Сначала оставались строки нужного owner и совпадающего actor. Затем главным ключом служила точность домена, вторым — локальной части. Точное совпадение было лучшим; среди шаблонов выигрывал более короткий и узкий.

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

Существовали и значения по умолчанию. Сам owner и сервисы APEX его домена получали широкие права, сервисы APEX любых доменов — core:data, прочие глобальные субъекты — all:none. Явная запись заменяла лишь default с тем же значением actor. Полный снимок политики включал и невидимые стандартные правила.

Отрицательная запись несла смысл

Удаление выполнялось set с owner, actor и текущей версией, но без actions. Сервис убирал запись, отвечал инициатору и отдельно отправлял owner уведомление set без действий.

Далее RFC предупреждает: из-за шаблонов удаление может изменить разрешение вместо его уничтожения. all:none означает отсутствие любых операций. Оставленная точная запись прекращает поиск раньше широкой и сохраняет запрет.

Это отрицательная информация, которую нельзя выразить отсутствием. Нет исключения — применяется общее правило. Есть точный deny — наследование запрещено. Если очистка удалит deny как пустой tombstone, доступ появится без нового разрешающего изменения.

Версия закрывала гонку записи

Перед изменением приложение обычно читало запись и lastUpdate. Замена или удаление повторяли полученное значение. Если точной записи больше не было либо версия семантически отличалась, сервис возвращал 555. Создание выполнялось без lastUpdate.

Сравнение предотвращало перезапись изменения, сделанного после чтения. После создания или обновления сервис ставил новое время, отличное от предыдущего.

Совпадение версии не доказывало, что owner получил уведомление, все реплики увидели состояние и точка enforcement начала отказывать. Цепочка включает чтение, версию, запрос, успех или конфликт, новый объект, отправку и доставку уведомления, пересчёт, распространение и пробную операцию.

На запрос политики тоже требовалось право

Сервис проверял принадлежность subject домену и действительность адреса. Затем выбирал запись subject, совпадающую с инициатором запроса, и требовал access:query. Только после этого находил запись для проверяемого actor и выяснял, содержатся ли все запрошенные действия.

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

Записи требовалось держать в постоянном хранилище независимо от подключения owner. Отключение не отзывает политику. Постоянство не служило доказательством репликации, свежести или исполнения.

Переход в Historic

RFC 3341 вышел в июле 2002 года на Standards Track вместе с ядром, опциями и присутствием APEX. История IETF за 29 июля 2012 года объясняет перевод RFC 3340–3343 в Historic: насколько было известно IETF, реализации не развёртывались, а функции предоставлял широко развёрнутый XMPP из RFC 6120 и RFC 6121.

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

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

Источники