Кратко

  • ACL почтового ящика состоит из пар «идентификатор—права». Один пользователь может совпасть с личным именем, группами и anyone, поэтому строка остаётся лишь входом вычисления.
  • GETACL показывает записанные правила, LISTRIGHTS — что сервер способен назначить идентификатору, а MYRIGHTS — действующий итог для текущей сессии.
  • DELETEACL убирает пару; отрицательный идентификатор вычитает право при расчёте. RFC 4314 уточнил границу, не навязав серверам единую локальную модель личности.

Строка исчезла раньше полномочия

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

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

RFC 1730 описал удалённый ящик как сетевой объект, которым управляет клиент: выбирает папки, читает сообщения, меняет флаги и состояние на сервере. При совместной работе локальных файловых разрешений, невидимых клиенту, уже не хватало. Клиенту требовался ответ того компонента, который выполнит следующую команду.

В январе 1997 года Standards Track RFC 2086 добавил capability ACL. Список доступа к ящику стал множеством пар идентификатора и строки прав. Их можно было запросить и изменить, не выгружая весь каталог учётных записей.

Одна сессия приходила под несколькими именами

anyone зарезервировали для всеобщей идентичности, включая анонимную. Имена, принимаемые LOGIN или AUTHENTICATE, соответствовали пользователям. Другие строки могли обозначать группы и иные категории, смысл которых определяла реализация.

Фред поэтому мог одновременно совпадать с fred, support-team и anyone. RFC не установил одну алгебру. Сервер мог объединить права всех подходящих идентификаторов или использовать только самый конкретный.

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

Протокол не стал строить центральную идентичность. Команда MYRIGHTS спрашивала сервер о действующих правах подключённого пользователя на ящик. Будущий исполнитель операции сообщал собственный текущий расчёт.

Три вопроса о трёх состояниях

GETACL возвращал сохранённые пары. Он отвечал, какие правила объявлены, но не какие относятся к этой сессии и как они складываются.

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

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

Повторное чтение ACL, ответ MYRIGHTS и принятие защищённой команды — разные доказательства. Запись правила может пройти без изменения итога; один новый итог не описывает старые сессии; успешная операция не устанавливает личность оператора.

Удалить основание или вычесть право

DELETEACL mailbox fred удалял пару Фреда. Если w продолжала давать группа или anyone, команда полностью выполняла свой контракт и сохраняла запись в ящик.

RFC 2086 зарезервировал идентификаторы с дефисом для отрицательных прав. RFC 4314 подробно развёл операции. Запись -fred с w вычитала у Фреда право записи, даже если его давал другой совпавший идентификатор. Отрицательная запись участвовала в расчёте; DELETEACL лишь удалял одну пару.

Поддержка отрицательных идентификаторов оставалась необязательной. Клиент не мог обещать универсальный переключатель «запрет сильнее разрешения». Он должен был выяснить возможности сервера и проверить действующий результат.

Дефис имел и другое место. В аргументе прав SETACL значение -w удаляло w из выбранной пары. В позиции идентификатора -fred становился отрицательным входом вычисления. Первая запись редактировала строку, вторая могла перекрыть унаследованный путь.

Уточнение прав без разрыва со старым кодом

Вариант 1997 года обозначал буквами видимость, чтение, состояние прочтения, прочие флаги, вставку, отправку, создание, удаление и администрирование. c и d оказались неоднозначными: пометить сообщение удалённым, окончательно очистить его и удалить весь ящик — разные действия.

В декабре 2005 года RFC 4314 заменил RFC 2086. k стал управлять созданием дочерних ящиков, x — удалением или перемещением ящика, t — флагом удаления сообщения, e — очисткой. Старые c и d сохранились как виртуальные права совместимости. Новый сервер применял точную модель и одновременно возвращал старому клиенту определённую грубую проекцию.

Capability RIGHTS= объявляла дополнительные права. Если реализация могла назначить несколько операций только вместе, LISTRIGHTS показывал связь. Общий стандарт не притворялся, что все локальные системы одинаково дробят власть.

Редактор ACL также обязан был сохранять неизвестные права, если не позволял пользователю менять их. Иначе старый клиент читал современную строку и при сохранении стирал всё, чего не понимал. Совместимость потребовала консервативного отношения к незнанию.

Отзыв имел временную границу

RFC 4314 разрешил серверу кэшировать права при выборе ящика. После SETACL или DELETEACL уже открытая сессия могла выполнять STORE или EXPUNGE по старому расчёту до нового выбора.

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

В одном соединении порядок был определим. Если клиент отправлял SETACL и MYRIGHTS конвейером, изменение должно было завершиться до второго расчёта. О кэше другого соединения эта гарантия ничего не говорила.

Список полномочий сам был секретом

ACL раскрывала существование ящика, имена пользователей, группы и администраторов. RFC 2086 запретил неуполномоченному GETACL выдавать защищённый объект. RFC 4314 потребовал без права видимости отвечать так же, как для несуществующего ящика.

Чтение сообщений не давало автоматического права видеть ACL: карта идентификаторов была отдельной информацией безопасности. Расширение и не шифровало её само. Без STARTTLS, согласованной защиты аутентификации или другого механизма данные шли открыто.

Верная авторизация и конфиденциальный транспорт ответа оставались разными задачами.

Локальный остаток был признан

RFC 4314 перечислил недостатки: объединение прав зависело от реализации, пользователи, группы и специальные идентификаторы делили пространство имён, универсальный понятный интерфейс был ограничен, а полный аналог смены владельца отсутствовал.

Совместимое уточнение всё же считалось полезным, поскольку RFC 2086 уже работал в нескольких реализациях. RFC 9051 позже определил IMAP4rev2 и в общем сохранил применимость зарегистрированных расширений IMAP4rev1. Это непрерывность протокола, а не доказательство нынешнего всеобщего внедрения ACL или отрицательных прав.

Исторический итог скромнее центральной системы управления: IMAP стандартизировал вопросы, которые позволяют отличить записанное правило, допустимое изменение и полномочие, вычисленное исполняющим кодом.

Источники