Всем привет.

Проблема с RLS следующая.

На таблицу O1.T_DATA1 наложена политика уровня строк. Функция возвращает предикат:



Пользователь имеет доступ к таблице O1.T_DATA1 (read), но не имеет доступа к O2.T_DATA2.

Пользователь-владелец пакетной функции, используемой в политике, имеет привилегию select any table.

При выполнении запроса пользователь получает результат 0 строк:



Документация гласит:
https://docs.oracle.com/database/121/ARPLS/d_rls.htm Overview
...
If the predicate contains subqueries, then the owner (definer) of the policy function is used to resolve objects within the subqueries and checks security for those objects. In other words, users who have access privilege to the policy-protected objects do not need to know anything about the policy. They do not need to be granted object privileges for any underlying security policy. Furthermore, the users do not require EXECUTE privilege on the policy function, because the server makes the call with the function definer's right.
...
Security Model
A security check is performed when the transient view is created with a subquery. The schema owning the policy function, which generates the dynamic predicate, is the transient view's definer for security check and object lookup.

Вопрос. Правильно я понимаю, что для получения результата подзапроса в предикате (таблица O2.T_DATA2) должны использоваться права владельца пакетной функции, а не того пользователя, который читает таблицу O1.T_DATA1?
Если это так, то почему результат 0 строк?

Если функция возвращает предикат в следующем виде, то всё работает правильно - пользователь видит только те строки, которые ему можно видеть:



Oracle Enterprice 12c 12.1.0.2.0 64-bit

Спасибо заранее!

Ошибки при запросе к T1 нет.
Предикат должен был ограничить доступ к одной строке, но в итоге ограничивает полностью - скорее всего из-за того, что у пользователя нет прав на чтение T2. Но как в этом случае понимать документацию, из которой следует, что реализация политики и внутренности transient view должны оставаться "прозрачными"?
Может, ещё какие идеи? Не знаю, куда ещё копать.

В общем, картина такая.

Таблицы:
O1.T_DATA1 t1 - на которую наложена политика, в которой скрываем строки.
O2.T_DATA2 t2 - которая входит в подзапрос предиката, возвращаемого функцией политики.

Пользователи:
USER1 - выполняет запрос к таблице t1. Имеет роль, у которой есть привилегия read on O1.T_DATA1.
O1 - техническая УЗ, схема для хранения данных, без особых привилегий.
O2 - техническая УЗ, схема для хранения данных, без особых привилегий.
O3 - техническая УЗ, схема для хранения всего, что связано с безопасностью, в частности функций политик. Имеет системные привилегии select any table (admin_option = NO), exempt access policy и некоторые другие, выданные непосредственно.

Проверили на 19 версии, работает аналогично:

null не возвращает, на столбце ограничение not null.

Чем всё закончилось.

Действительно, в соответствии с документацией, получение данных из таблицы O2.T_DATA2, участвующей в подзапросе предиката, выполняется от имени владельца пакетной функции, который имеет привилегии select any table и exempt access policy - то есть проблем с этим подзапросом потенциально возникнуть не должно.

Однако, на таблицу O2.T_DATA2 наложена политика, маскирующая значения в столбце FN_ID. Напомню, что предикат следующий:


Оказалось, что при "раскрытии" подзапроса эта политика почему-то срабатывает для конечного пользователя, не смотря на то, что в "раскрытии" участвует владелец функции (с привилегией exempt access policy). Таким образом, подзапрос предиката возвращал набор null-ов, что в итоге приводило к получению 0 строк из таблицы O1.T_DATA1.

Отключение политики на таблице O2.T_DATA2 решило проблему.

Теперь остаётся один вопрос: почему для пользователя, выполняющего select из таблицы O1.T_DATA1, срабатывает политика таблицы O2.T_DATA2, участвующей в подзапросе? В документации про это не сказано.

https://docs.oracle.com/database/121/ARPLS/d_rls.htm Overview
...
If the predicate contains subqueries, then the owner (definer) of the policy function is used to resolve objects within the subqueries and checks security for those objects. In other words, users who have access privilege to the policy-protected objects do not need to know anything about the policy. They do not need to be granted object privileges for any underlying security policy. Furthermore, the users do not require EXECUTE privilege on the policy function, because the server makes the call with the function definer's right.
...
Security Model
A security check is performed when the transient view is created with a subquery. The schema owning the policy function, which generates the dynamic predicate, is the transient view's definer for security check and object lookup.

Всем спасибо за участие!