Запретить привилегии для пользователя - PullRequest
Новая
       10

Запретить привилегии для пользователя

0 голосов
/ 05 июня 2019

Есть ли способ предотвратить (отозвать) привилегии, такие как:

create table, create package, create function и т. Д.,

от пользователя в его собственной схеме, но разрешить ему выполнять эти действия длядругой пользователь.

exmaple: 

-- connected as DP1

-- will raise an exception
create table dp1.tst (id number);


-- no exception
create table dp2.tst (id number);

Спасибо.

Ответы [ 2 ]

1 голос
/ 05 июня 2019

В общем случае это невозможно.

Вы можете предоставить привилегию типа GRANT CREATE TABLE TO DP1, которая позволяет пользователю DP1 создавать таблицы в своей собственной схеме.

Или вы можете предоставить такую ​​привилегию, как GRANT CREATE ANY TABLE TO DP1, которая позволяет пользователю DP1 создавать таблицы в любой схеме - которая, конечно, включает в себя его собственную схему.

Одним из решений может быть такая процедура: 

create or replace procedure DP2.create_table(ddl in varchar2) as

begin
   if regexp_like(ddl, '^CREATE TABLE DP2.', 'i') then
      execute immediate ddl;
   end if; 
end;
/

grant execute on DP2.create_table to DP1;

Однако я считаю это уродливым решением проблемы. execute immediate ddl создает потенциальные недостатки безопасности, и процедура подвержена ошибкам.

Другим подходом может быть Триггер базы данных : 

GRANT CREATE ANY TABLE TO DP1;

CREATE OR REPLACE TRIGGER CREATE_TABLE_CHECK
   BEFORE CREATE ON DATABASE 
BEGIN
   IF ora_login_user = 'DP1' THEN
       IF NOT (ora_dict_obj_owner = 'DP2' AND ora_dict_obj_type = 'TABLE') THEN
          RAISE_APPLICATION_ERROR(-20001, 'You are permitted only to create TABLES in schema "DP2"');
       END IF;
   END IF;
END;

Но вам лучше пересмотреть свои требования к дизайну.

0 голосов
/ 05 июня 2019

Вы можете отозвать эти привилегии из DP1, но затем разрешить им управлять объектами в DP2, как объясняет @Wernfried, непросто. Вы также можете использовать привилегии CREATE ANY с триггером DDL, при котором ошибки для DDL запускаются со схемой DP1, но это даже сложнее, и привилегий ANY действительно следует избегать для общего использования, поскольку они настолько мощные.

Вместо этого вы можете настроить прокси-аутентификацию: 

alter user DP2 grant connect through DP1;

тогда вместо подключения DP1, как говорят: 

sqlplus dp1/dp1passwd@db

затем можно подключить как: 

sqlplus dp1[dp2]/dp1passwd@db

Им не нужно знать пароль учетной записи для DP2 - они по-прежнему проходят аутентификацию, используя свой собственный пароль учетной записи. Механизм сквозного прокси-сервера означает, что они теперь находятся в сеансе как DP2, для всех целей и задач. Любой DDL будет против схемы DP2, и контрольный журнал может показать, что действия были выполнены через прокси-сервер и кем был реальный пользователь (то есть DP1). У них будут роли и привилегии DP2, поэтому они смогут управлять объектами в этой схеме, даже если у них нет привилегий создания для их собственной учетной записи.

Они даже не смогут увидеть что-либо в своей собственной схеме DP1 (если они не предоставили привилегии DP2); но поскольку в этом сценарии им ничего не принадлежит, то это спорный вопрос.

Конечно, это не просто доступно в SQL * Plus, вы можете использовать его через OCI, JDBC и т. Д.

Подробнее .

...