Предоставление разрешения пользователей на другую схеме

Question

У меня есть таблицы в схеме А. я создал мнение в схемах B с использованием таблиц в схеме А.

Я хочу предоставить разрешение пользователя выбирать данные из поля зрения в схеме B.

Для этого я знаю, что нам нужно включить параметр гранта для таблиц в схеме A для пользователя B. Но я хочу сделать это в одном скрипте (этот скрипт должен быть в схеме B). Есть ли способ сделать это, используя имя пользователя/пароль схемы A.

Answer 1

Только подключаясь как пользователь A в какой-то момент. Вы все еще можете сделать это в одном сценарии, если вы действительно хотите:

connect userA/passwordA 
grant select on my_table to userB; 
connect userB/passwordB 
create view my_view as select * from userA.my_table; 

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

Если вы хотите, чтобы другие пользователи могли выбирать из представления, вам не нужно предоставлять явные разрешения для userA.my_table; пока владелец представления может видеть основную таблицу, другие пользователи просто должны иметь возможность видеть представление. Который часто бывает точкой (или одним из них), поскольку вы можете ограничить представление только тем, чтобы отображать выбранные данные из базовой таблицы в остальную часть мира. Я предполагаю, что у вас есть причина не создавать представление в схеме A.

Я не уверен, действительно ли вы спрашиваете о том, чтобы предоставить пользователю B вариант с возможностью администратора, чтобы пользователь B мог затем предоставить выделение для пользователя A стол для других людей. Если это возможно, это не похоже на хорошую идею и не обязательно, чтобы представление работало.

Answer 2

Нет ничего необычного в том, чтобы иметь один скрипт для развертывания изменения. Дело в том, что такой скрипт должен запускаться мощным пользователем, потому что он должен иметь системные привилегии на ЛЮБОЙ уровне. Обычно это означает учетную запись DBA, предпочтительно учетную запись приложения, но в противном случае SYSTEM или SYS.

Так сценарий вы хотите, будет выглядеть следующим образом:

grant select on user_a.t23 to user_b 
/
grant select on user_a.t42 to user_b 
/
create view user_b.v_69 as 
select t23.col1, t42.col2 
from user_a.t42 
     join user_a.t23 
      on (t42.id = t23.id) 
/
grant select on user_b.v_69 to user_c 
/

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

Один из способов построить этот мастер-скрипт должен использовать изменить синтаксис CURRENT_SCHEMA:

alter session set current_schema=USER_A 
/
@run_grants_to_userb.sql 

alter session set current_schema=USER_B 
/
@create_view69.sql 
@run_grants_to_userc.sql 

Нам все еще нужно пользователю DBA запустить мастер сценарий. Одно из преимуществ переключения текущей схемы заключается в том, что она позволяет нам развертывать объекты, такие как ссылки на базы данных, которые через причуду синтаксиса не могут иметь имя схемы в своем объявлении. Одна из них заключается в том, что пользователь не изменяется, поэтому скрипт, который использует псевдо-столбец USER, может привести к нежелательным результатам.

Answer 3

Позвольте пользователю выделить грань на своих таблицах в B и включить «вариант гранта».

Как пользователь A:

GRANT select ON table TO user_b WITH GRANT OPTION; 

Пусть субсидия пользователь B выберите на его взгляды на пользователя А и включают в себя "вариант гранта.

Как пользователь B:

GRANT select ON view TO user_a WITH GRANT OPTION; 

Как пользователь A:

GRANT select on user_b.view TO user_c; 

Это позволяет пользователю A передать этот грант на других пользователей.

Answer 4

Просто Выполните запрос

GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE1 TO SCHEMA2;