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

Question

У меня есть таблицы в схеме A. Я создал представления в схеме B, используя таблицы в схеме A.

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

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

Answer 1

Просто запустите запрос

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

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 предоставит право выбора в своих представлениях пользователю A и включит «вариант предоставления».

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

GRANT select ON view TO user_a WITH GRANT OPTION;

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

GRANT select on user_b.view TO user_c;

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

Answer 4

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

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 другим людям. Если это возможно, это не звучит как хорошая идея и не является необходимым для работы представления.