Глава 13. Пересечение прав

13.1. Одно действие — несколько оснований

Для одного субъекта и объекта может существовать несколько независимых оснований доступа.

Например:

Owner       → READ
ProjectRole → READ
Group       → UPDATE

Если модель допускает независимые положительные основания, они могут совместно сформировать эффективный набор прав:

READ ∪ UPDATE

Но это не универсальное правило.

В одной модели несколько оснований действительно расширяют набор прав.

В другой одно отношение может ограничивать другое.

Поэтому нельзя заранее утверждать, что все права всегда объединяются.

Способ комбинирования является частью правил конкретной модели.

13.2. Право и ограничение

Особенно важно различать:

permission

и

constraint

Право отвечает:

Какое действие может быть выполнено?

Ограничение отвечает:

При каких условиях это действие допустимо?

Например:

Role → UPDATE

может существовать одновременно с условием:

Object state = DRAFT

Тогда право UPDATE существует, но применяется только в определённом состоянии.

Получается:

Permission + Applicability condition

а не просто один бит разрешения.

13.3. Область действия остаётся частью результата

Если субъект получил:

READ

нельзя потерять информацию о том, где это право действует.

Например:

READ in Project A

и

READ in Project B

— разные результаты.

Поэтому эффективное разрешение концептуально должно сохранять область действия:

Permission + Area

а не превращаться в глобальное:

READ

Иначе система может случайно распространить право за пределы исходного отношения.

13.4. Отсутствие права и явный запрет

Ещё одно важное различие:

permission absent

и

explicit deny

не обязательно означают одно и то же.

В модели без явных запретов отсутствие разрешения может означать:

Deny

Но в модели, где существуют отрицательные правила, нужно отдельно учитывать:

ALLOW
DENY

и правила их взаимодействия.

Нельзя объявлять приоритет DENY универсальным свойством любой модели доступа.

Он является частью конкретной политики.

13.5. Что происходит в Guardian

В текущей модели Guardian нет общего механизма произвольного конфликта ALLOW/DENY.

Проверка использует маски разрешений.

Концептуально обычная ветка выглядит так:

effective_user_permission
        ∩
object_scope
        ∩
required_permission
        ≠ ∅

В текущей реализации это выражено через побитовое пересечение:

(effective_permission
 & object_scope_permission
 & required_mask) != 0

Это не универсальная формула для всех систем.

Это конкретное правило текущей модели Guardian.

effective_user_group при этом не проверяется непосредственно во время has_object_permission().

Он участвует раньше — при построении производных разрешений и обработке Scope Barrier.

13.6. Почему нельзя просто сложить все права

Предположим:

Role A → UPDATE
Role B → APPROVE

Из этого может следовать:

UPDATE + APPROVE

Но если одно из правил означает ограничение области:

Role A → UPDATE in Project A
Role B → APPROVE in Project B

то объединять их в:

UPDATE + APPROVE everywhere

нельзя.

Следовательно, эффективный результат должен сохранять не только сами действия, но и условия их применимости.

13.7. Пересечение как свойство конкретной модели

Таким образом, «пересечение прав» — это не один математический оператор, применимый ко всем системам.

В разных моделях встречаются:

• объединение независимых разрешений;

• пересечение ограничений;

• приоритет одного правила;

• явные запреты;

• условия применимости;

• ограничения по области;

• ограничения по состоянию.

Поэтому правильный архитектурный вопрос звучит не так:

Какой оператор использовать для прав?

а так:

Какие правила определяют результат, если несколько оснований одновременно применимы?

13.8. Эффективное разрешение как результат правил

Итоговая схема:

Source facts
      ↓
Relevant context
      ↓
Applicable grounds
      ↓
Rules
      ↓
Combination / constraints
      ↓
Effective permission
      ↓
Requested action

В Guardian конкретное правило для обычной проверки объекта можно представить как:

if
    (effective_user_permission.permission_mask
     &
     object_scope.permission_mask
     &
     required_mask) != 0
then
    ALLOW
else
    DENY

Отдельно существует ветка владельца, где право владельца проверяется через соответствующий OWNER-scope объекта.

Это уже не абстрактная модель, а пример того, как общая архитектура превращается в конкретное правило.