2015-05-08 4 views
0

Мне просто интересно, есть ли возможность предоставить разрешение на создание синонимов на разных схемах без предоставления опции «ЛЮБОЙ». Я просто хочу сузить грант, чтобы предоставить разрешение на то, что требуется для целей безопасности.Предоставить создание синонимов на другой схеме (Oracle)

Мы создали имя схемы A, относящееся к продукту приложения. Но приложение допускает доступ к объекту через другую (логин) схему B. Мы предоставили ресурс схеме A, поэтому схема. Владелец может создавать свои собственные объекты. Какой синтаксис синтаксиса я должен использовать, чтобы предоставить схему A для создания синонимов на схеме B, чтобы она могла создавать синонимы.

Конечный результат должен быть, как показано ниже, и может быть создан владельцем схемы А без вмешательства DBA

B.b_synonym maps to A.b_object 
+0

То, что вы пытаетесь выполнить, похоже, не имеет смысла. Если 'B' владеет таблицей, зачем вы хотите создать частный синоним в схеме' B'? Этот синоним можно использовать только «B», который по определению имеет доступ к базовой таблице. 'A' никогда не может использовать частный синоним, определенный в схеме' B' (отсюда и имя private). Если вы хотите создать частный синоним, было бы разумно создать его в схеме 'A'. Или, возможно, вы хотите создать публичный синоним. –

ответ

2

Вам нужно Созданное ЛЮБОЙ SYNONYM привилегию, чтобы сделать это, как A, поэтому

GRANT CREATE ANY SYNONYM TO A; 

EDIT: Для того, чтобы избежать каких-либо льгот, сделать это:

а), A:

GRANT SELECT ON mytable1 TO B; 
GRANT SELECT, INSERT, UPDATE, DELETE ON mytable2 TO B; 

б) в качестве B:

CREATE SYNONYM a_mytable1 FOR A.mytable1; 
CREATE SYNONYM a_mytable2 FOR A.mytable2; 
+0

Я не хочу давать ЛЮБОЕ из-за проблем с безопасностью. – user1595858

+0

В этом случае B должен создать синоним. –

+0

Но B нуждается в привилегии, чтобы увидеть объекты A. Я не думаю, что у меня есть опция здесь, так как Admin я создал синонимы. – user1595858

0

Вы не можете предоставить привилегии, которые применяются только к одной другой схеме. Вы должны были бы предоставить ЛЮБОЙ - даже если временно, например. во время создания/изменения основной схемы A, чтобы уменьшить влияние безопасности - и создать все синонимы в другой схеме пользователя B, пока у вас есть привилегии. В противном случае пользователю B пришлось бы создавать сами синонимы; или пользователь A может создавать общедоступные синонимы.

В качестве альтернативы, имеющие какие-либо синонимы, вы могли бы пользователь B переключатель для схемы А с:

alter session set current_schema = A; 

Они могли бы ссылаться на объекты А, не имея префикс их с именем схемы, хотя они тогда не могли видеть никаких объектов в своей собственной схеме без их префикса - это не похоже на то, что у B будут объекты, но трудно сказать.

Вы также можете автоматизировать этот переключатель схемы с помощью триггера входа:

create or replace trigger ramread_logon_trigger 
after logon on database 
begin 
    if user = 'B' then 
    execute immediate 'alter session set current_schema = A'; 
    end if; 
end; 
/

Если вы на самом деле есть несколько пользователей вы можете использовать роль вместо этого, и переключить схему для любого пользователя, который имеет эту роль, путем тестирования с dbms_session.is_role_enabled. Одной и той же роли могут быть предоставлены необходимые разрешения для доступа к объектам A, которые вам нужно каким-то образом предоставить - синоним сам по себе не дает никаких прав доступа.

Смежные вопросы