Формулируем правила доступа

Наша цель – разрешить разным пользователям Oracle работать (SELECT, INSERT, UPDATE, DELETE) только с сотрудниками из таблицы EMP определенных отделов.

Для этого создадим в SQL*Plus регламентирующую таблицу, которую назовем UDPERMISSIONS:

CONNECT / AS SYSDBA

CREATE TABLE udpermissions (username VARCHAR2(14), deptno NUMBER (2));

INSERT INTO udpermissions VALUES ('SCOTT', 10);

INSERT INTO udpermissions VALUES ('SCOTT', 30);

INSERT INTO udpermissions VALUES ('ADAM', 10);

(Полагаем, что пользователь SCOTT будет работать с сотрудниками 10 и 30 отделов, а пользователь ADAM – с сотрудниками только 10).

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

CREATE OR REPLACE FUNCTION deptsallowed ( obj_schema IN VARCHAR2 ,obj_name IN VARCHAR2 ) RETURN VARCHAR2 IS BEGIN RETURN 'deptno IN (SELECT deptno FROM udpermissions ' 'WHERE username = USER)'; END; /

Замечание. У функции DEPTSALLOWED два неиспользуемых в теле параметра. Не использовали мы их для простоты, а при желании могли бы и использовать для передачи имен схемы и таблицы, задав функцией более сложную логику. С другой стороны опыт показал, что для безошибочной работы параметры должны быть объявлены.

Тут же создадим под именем EPOLICY «политику доступа» к таблице SCOTT.EMP на основе созданного только что предиката:

BEGIN DBMS_RLS.ADD_POLICY

( POLICY_NAME => 'epolicy'

,OBJECT_SCHEMA => 'scott'

,OBJECT_NAME => 'emp'

,FUNCTION_SCHEMA => 'sys'

,POLICY_FUNCTION => 'deptsallowed'

); END; /

Перечень имеющихся «политик» можно посмотреть в таблицах DBA(USER)_POLICIES.

Так как функция DEPTSALLOWED принадлежит SYSTEM, а связываться в нашем случае она будет с таблицей SCOTT.EMP, не забудем дать пользователю SCOTT право к этой функции обращаться (неявно, через созданную политику):

GRANT EXECUTE ON deptsallowed TO scott;

Содержание раздела

---

---