1470

Глава 21

5 /

PL/SQL procedure successfully completed. tkyte@TKYTE816> begin

2 dbms rls.add policy

3 (object name => C,

4 policy name => C POLICY,

5 policy function => pred function,

6 statementtypes => DELETE);

7 end;

PL/SQL procedure successfully completed.

то окажется, что нельзя удалить ни одной строки из таблицы С с помощью SQL-опера-тора:

tkyte@TKYTE816> delete fromG;

0 rows deleted.

Установленное правило защиты не позволяет это сделать. Наличие строки в таблице С (в результате вставки в предыдущем примере) легко проверить:

tkyte@TKYTE816> select * from G;

Простое удаление строки в главной таблице:

tkyte@TKYTE816> delete from P;

1 row deleted.

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

tkyte@TKYTE816> select * fromG;

no rows selected

Изменение строк

Аналогичная ситуация при удалении строк из главной таблицы возникает и при пользовании в требовании целостности конструкции ON DELETE SET NULL. Немного изменим пример, чтобы, благодаря требованию целостности ссылок, можно было изменять строки в таблице С, которые нельзя изменять SQL-операторами. Начнем с пересоздания таблицы С, задав для внешнего ключа конструкцию ON DELETE SET NULL.

tkyte@TKYTE816> drop table c;

Table dropped.

tkyte@TKYTE816> create table c (x int references p on delete set null); Table created.

Тщательный контроль доступа 1471

tkyte@TKYTE816> insert into p values (1);

1 row created.

tkyte@TKYTE816> insert into c values (1);

1 row created.

Теперь зададим ту же функцию, что и в предыдущих примерах, в качестве правила защите! для изменения данных в таблице С, и установим флагу UPDATE CHECK значение TRUE. Это не позволит изменять строки:

tkyte@TKYTE816> begin

2 dbms rls.add policy

3 (object name -> С,

4 policy name => C POLICY,

5 policy function => pred function,

6 statement types => UPDATE,

7 update check => TRUE);

8 end;

PL/SQL procedure successfully completed.

tkyte@TKYTE816> update c set x = NULL;

0 rows updated.

tkyte@TKYTE816> select * from c; 1

Итак, с помощью SQL-операторов строки в таблице С изменять нельзя. Однако удаление строк из таблицы P показывает следующее:

tkyte@TKYTE816> delete from p;

1 row deleted.

tkyte@TKYTE816> select * from c;

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

tkyte@TK:E816> delete from c;

1 row deleted.

tkyte@TKYTE816> insert into p values (1);

1 row created.

tkyte@TKYTE816> insert into c values (1);

1 row created.

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

1472

Глава 21

tkyte@TKYTE816> create or replace function pred function

2 (p schema in varchar2, p object in varchar2)

3 return varchar2

4 as

5 begin

6 return x is not null;

7 end;

Function created.

tkyte@TKYTE816> update c set x = NULL; update c set x = NULL

ERROR at line 1:

ORA-2 8115 : policy with check option violation

Это изменение завершилось неудачно, поскольку условие X IS NOT NULL не будя выполняться после изменения. Если теперь снова удалить строку из таблицы P:

tkyte@TKYTE816>delete from p;

1 row deleted.

tkyte@TKYTE816> select * from c;

строка в таблице С получит значение, которое нельзя задать с помощью SQL-оператора непосредственно.

Кэширование курсоров

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

5 as

6 begin

7 if (user = p schema) then

8 return ;

9 else

10 return owner = USER

11 end if;

12 end;

оказывается, что она возвращает либо пустое условие, либо условие owner = USER. Ho в течение сеанса она постоянно возвращает одно и то же условие. Невозможно получить условие owner = USER, a затем в том же сеансе получить пустое условие. Чтобы понять, почему это принципиально важно для корректного использования средств тщательного контроля доступа в приложении, надо разобраться, когда условие связывается