Совместное использование представлений Oracle между пользователями с существующими разрешениями на таблицы

Question

Возможно ли предоставить разрешение на использование представления, когда грантополучатель уже имеет права выбора для базовых таблиц, но у лица, предоставляющего право, нет разрешений «с грантом» для этих таблиц? То есть, может ли грантополучатель использовать структуру представления, но с собственными базовыми разрешениями таблиц, а не разрешениями владельца представления?

Например, у меня есть пользователи A, B и C. Пользователь A имеет несколько таблиц. Пользователи B и C в настоящее время имеют одинаковые разрешения для этих таблиц. Пользователь B создает представление для этих таблиц. Может ли пользователь C использовать это представление?

Примечание: Я знаю, что если для B заданы разрешения «выбирать с грантом», которые могут выполняться на разрешениях B, но я не хочу, чтобы B мог предоставлять свои права на пересылку; Я хочу, чтобы пользователи, у которых уже есть собственные права, могли использовать структуру представления.

Контекст: Я хотел бы сделать какую-то специальную работу, используя некоторые данные в схеме A, как запросы через представления, уже присутствующие в схеме B; это связано с созданием некоторых таблиц для хранения наборов данных, с которыми я хочу работать, но я не хочу загромождать схему B этими таблицами во время работы. Могу ли я сделать это как пользователь C, просто скопировав разрешения пользователя B на схему A, не задумываясь также о воссоздании всех представлений пользователя B в схеме C? Есть ли более простой способ сделать это?

Answer 1

Короткий ответ «Нет». documentation is quite clear:

Чтобы предоставить ВЫБРАТЬ на представлении другому пользователю, либо вы должны владеть все объекты, лежащие в основе представления или вам должны быть предоставлены Выбор объекта привилегии WITH GRANT OPTION на всех этих базовых объектов. Это верно, даже если у получателя уже есть привилегии SELECT для этих базовых объектов.

Вот проработанный пример. Сначала гранты ...

SQL> grant select on product to b; 

Grant succeeded. 

SQL> grant select on sales to b; 

Grant succeeded. 

SQL> grant select on product to c; 

Grant succeeded. 

SQL> grant select on sales to c; 

Grant succeeded. 

SQL> conn b/b 
Connected. 
SQL> select count(*) from a.sales; 

    COUNT(*) 
---------- 
     40 

SQL> conn c/c 
Connected. 
SQL> select count(*) from a.sales; 

    COUNT(*) 
---------- 
     40 

SQL> 

Теперь давайте создадим представление в схеме B.

SQL> conn b/b 
Connected. 
SQL> create or replace view tot_product_sales as 
    2 select p.name as product_name 
    3   , sum(s.pieces) as units_sold 
    4   , sum(s.pieces * p.price) as turnover 
    5 from a.sales s 
    6   join a.product p on p.product_id = s.product_id 
    7 group by p.name 
    8/

View created. 

SQL> select * from tot_product_sales 
    2/

PRODUCT_NAME     UNITS_SOLD TURNOVER 
------------------------------ ---------- ---------- 
Mobile        1161  928800 
Laptop        970 1552485 

SQL> grant select on tot_product_sales to c; 
grant select on tot_product_sales to c 
       * 
ERROR at line 1: 
ORA-01720: grant option does not exist for 'A.PRODUCT' 


SQL> 

---

Почему модель безопасности Oracle это сделать? Подумайте об этом следующим образом: GRANT SELECT, позволяет пользователю B, чтобы сделать две вещи с данными А в

• выбор данных из таблиц А в
• with grant option, разрешать другим пользователям выбирать данные из таблиц А в

Там не предоставлена ​​возможность для B знать, какие другие пользователи A предоставили привилегии. Поэтому B не может знать, какие привилегии C имеют в схеме A.

Решения?

1. A гранты select ... with grant option до B (и C)?
2. B и C создавать дублирующие просмотры
3. А создает вид и гранты выберите на нем до B и C

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

Ваша ситуация не подходит ни к одному из них, и поэтому кажется, что дублирование представлений в схеме C является вашей лучшей сетью.