CaS requests authorization

На сегодняшний день у нас есть CaS и есть ACL, но они не дружат. Грант выдается на функцию .proc_cas, но не на отдельные спейсы.

DoD:

• Документация на модель доступа (docs#68 (closed)) согласуется с поведением CaS
• Документация на CaS (RFC - Compare and swap) описывает правила авторизации запросов
• Все это реализовано в коде
• И покрыто тестами

Можно условно разделить на две части:

• DML - изменения пользовательских глобальных спейсов (pico.cas) !663 (merged)
• DDL/ACL - проверка привилегий при создании пользователей, спейсов, ролей + grant/revoke

changed milestone to %Picodata next

added 1 deleted label

added 1 deleted label

mentioned in issue #280 (closed)

added 1 deleted label

assigned to @rosik

marked this issue as related to sbroad#492 (closed)

marked this issue as related to #280 (closed)

changed milestone to %23.12.0

assigned to @d.rodionov and unassigned @rosik

Мне кажется грант на proc_cas не надо давать явно, эта функция должна быть публичной и доступной всем.

https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/_user/

Role 'public'.

Pre-defined role, automatically granted to new users when they are created with box.schema.user.create(user-name). Therefore a convenient way to grant ‘read’ on space ‘t’ to every user that will ever exist is with box.schema.role.grant('public','read','space','t').

По реализации предлагаются следующие изменения:

pico.cas становится доступна роли public. Т е становится доступна всем пользователям без предварительных проверок. При выполнении операции проверка прав доступа происходит на лидере. В случае ошибки доступа ошибка возвращается клиенту. В случае прохождения проверки запись применяется лидером.

Ошибка возникает после ответа клиенту, на этапе применения нет возможности зарепортить ее клиенту. Рассматриваю варианты.

Варианты:

• В случае ошибки применения записи дописывать ошибку в лог, и чтобы клиент ее выловил. Плохо потому что клиент не знает индекс записи с ошибкой заранее, т е не будет знать надо ли ему ждать следующей записи после получения записи о самом изменении.
• Попытаться вытащить функцию проверки пермишенов из тарантула, и звать ее на лидере перед propose чтобы была возможность вернуть клиенту ошибку до применения записи. Выглядит так что эта функция подходит: access_check_ddl
• Аналогично предыдущему, но реализовать проверку собственноручно не затрагивая тарантул на основе _pico_privilege.

Дополнительно стоит обратит ьвнимание что при проверке в propose необходимо так же проверить непримененные записи, т к иначе возможен рейс с записью revoke. В таком случае при применении cas записи возникнет ошибка.

В доке сейчас нет описания по CaS в отношении acl. Acl записи CaS сейчас генерируются только функциями нашего lua api. Т е описание необходимых пермишенов должно быть на этих функциях.

Соответственно в текущею доку доку: Для успешного выполнения операции пользователю необходимы права на запись в указанный спейс.

План:

• По умолчанию выдать права роли public на выполнение pico.cas
• Непривилегированному пользователю для выполнения cas на лидере требуется доступ в системный спейс. Проблему планируется решить повышением привилений в растокоде

Дополнительно стоит обратит ьвнимание что при проверке в propose необходимо так же проверить непримененные записи, т к иначе возможен рейс с записью revoke. В таком случае при применении cas записи возникнет ошибка.

В идеальном мире проврка привилегий должна была происходить при вставке записи в лимб. Соответственно и права в лимбе были бы настроены с учетом всех непримененных записей. Но пока лимба нет, придется накодить проверку по-скаутски.

mentioned in merge request picodata/tarantool!101

mentioned in merge request tarantool-module!373 (merged)

changed the description

marked the checklist item DML - изменения пользовательских глобальных спейсов (pico.cas) !663 (merged) as completed

mentioned in merge request tarantool-module!413 (merged)

mentioned in merge request !746 (merged)

mentioned in commit 5a319f3b

mentioned in commit 5089d025

closed with merge request !746 (merged)

closed with commit 5089d025

mentioned in commit 9e00aff2