1476

Глава 21

включает условие 1=0. Функция, возвращающая условие, на этот раз вообще не i-валась. Поскольку мы передали процедуре входные данные, PL/SQL-машина в1полни-ла и второй запрос. Для этого запроса, однако, еще нет открытого и проанализированного курсора, так что при выполнении он был проанализирован, с учетом непустого атрибута в контексте. Со вторым запросом SELECT * FROM T было связано условие x>0. Это и вызвало двусмысленность. Поскольку мы не можем управлять кэшированием курсора, возвращения в одном сеансе различных условий функцией, реализующей правила защиты, надо избегать любой ценой. В противном случае возможны плохо производимые и сложные для отладки ошибки в приложении. Ранее, в примере приложения для работы с информацией о сотрудниках, было продемонстрировано, как реализовать функцию, которая возвращает в ходе сеанса не более одного условия. Это гарантирует следующее.

Согласованность результатов запросов с точки зрения средств тщательного контроля доступа.

Неизменность условий защиты по ходу сеанса. Если они изменяются, возможна: странные и непредсказуемые результаты.

Зависимость правил защиты от пользователя, выполняющего операторы, но не от среды, в которой он работает.

В версиях Oracle 8.1.7 и выше результат будет следующим:

tkyte@dev817> exec dump t(0)

*** Результат выполнения оператора SELEGT * FROM T

1234

*** Результат выполнения другого оператора SELEGT * FROM T

1234

PL/SQL procedure successfully completed.

Во избежание описанных проблем сервер Oracle версий 8.1.7 и выше повторно анализирует запрос при изменении контекста сеанса, если с запросом связаны правила защиты. Подчеркиваю: при изменении контекста сеанса. Если для создания условия не используется контекст сеанса, снова возникает проблема, связанная с кэшированием курсора. Рассмотрим систему, в которой условия хранятся как данные в таблице базы данных. Такая система реализует правила защиты на основе таблицы. Если при этом содержимое таблицы правил изменится, вызывая изменение условия, мы столкнемся версии 8.1.7 с теми же проблемами, что и в 8.1.6, и более ранних версиях. Если нить предыдущий пример так, чтобы использовалась таблица базы данных:

tkyte@TKYTE816> create table policy rules table

2 (predicate piece varchar2(255)

3 )

Table created.

tkyte@TKYTE816> insert into policy rules table values (x > 0); 1 row created.

и изменить функцию, реализующую правила защиты так, чтобы она использовала таблицу:

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

tkyte@TKYTE816> create or replace function rls examp

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

3 return varchar2

4 as

5 l predicate piecevarchar2(255);

6 begin

7 select predicate piece into l predicate piece

8 from policy rules table; 9

10 return l predicate piece;

11 end;

12 /

Functioncreated.

то можно ожидать следующих результатов выполнения процедуры DUMP T (при изменении условия после в1полнения DUMP T без параметров, но до выполнения ее с параметром):

tkyte@DEV817> exec dump t

*** Результат выполнения оператора SELECT * ICM T

1234

PL/SQL procedure successfully completed.

tkyte@DEV817> update policy rules table set predicate piece = 1=0; 1 row updated.

tkyte@DEV817> exec dump t(0)

*** Результат выполнения оператора SELECT * FROM T

1234

*** Результат выполнения другого оператора SELECT * FROM T PL/SQL procedure successfully completed.

Обратите внимание, что при первом выполнении использовалось условие x>0, и запрос возвращал одну строку из таблицы Т. После выполнения этой процедуры мы изменили условие (это изменение можно было сделать из другого сеанса - его, например, мог сделать администратор). При втором выполнении процедуры DUMP T - с параметром, требующим выполнить после первого запроса второй, оказывается, что в первом запросе по-прежнему используется старое условие, x>0, тогда как во втором запросе - второе условие, 1=0, только что помещенное в таблицу POLICY RULES. Необходимо учитывать последствия кэширования курсора, даже в версиях 8.1.7 и выше, если только в правилах защиты наряду с таблицей не используется контекст приложения.

Хочу подчеркнуть, что изменять значение SYSCONTEXT по ходу работы приложения вполне допустимо. Эти изменения будут учтены и использованы при следующем выполнении запроса. Поскольку значения атрибутов контекста передаются как связываемые переменные, они вычисляются на этапе выполнения запроса, а не на этапе анализа, так что константы на этапе анализа не используются. Только текст условия не должен меняться по ходу работы приложения. Вот небольшой пример, демонстрирующий это. Завершим сеанс и снова зарегистрируемся (чтобы очистить кэш курсоров в сеансе), а затем изменим реализацию функции RLS EXAMP. Затем выполним те же действия, что и раньше:

1478

Глава 21

tkyte@TKYTE816>connecttkyte/tkyte

tkyte@TKYTE816> create or replace function rls examp

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

3 return varchar2

4 as

5 begin

6 return x > sys context(myctx,x);

7 end;

Function created.

tkyte@TKYTE816>set serveroutput on tkyte@TKYTE816> exec set ctx(NULL) PL/SQL procedure successfully completed. tkyte@TKYTE816> exec dump t

*** Результат выполнения оператора SELEGT * FROM T PL/SQL procedure successfully completed. tkyte@TKYTE816> exec set ctx(l) PL/SQL procedure successfully completed. tkyte@TKYTE816> exec dump t(0)

*** Результат выполнения оператора SELEGT * FROM T

1234

*** Результат выполнения другого оператора SELEGT * FROM T

1234

PL/SQL procedure successfully completed.

На этот раз оба запроса вернули одинаковые результаты. Это связано с тем, что они используют одинаковую конструкцию WHERE и в условии динамически обращаются к значению атрибута в контексте приложения.

Следует упомянуть, что бывают случаи, когда изменение условия по ходу сеанса может оказаться необходимым. Для этого приходится специальным образом программировать приложения, обращающиеся к объектам, правила защиты котор1х допускают изменение условий по ходу сеанса. Например, в PL/SQL придется использовать в приложении исключительно динамический SQL, чтобы избежать кэширования курсоров. При использовании этого способа поддержки динамических условий следует помнить, что результаты будут зависеть от того, как написано клиентское приложение, так что подобным образом универсальные правила защиты реализовать не удастся. Мы не будем рассматривать этот способ использования средств пакета DBMS RLS, а сосредоточимся на его исходном назначении - защите данных от несанкционированного доступа.

Экспортирование/Импортирование

Эту проблему мы уже упоминали. Необходимо быть внимательным при использовании утилиты ЕХР для экспортирования данных и утилиты IMP для их импортирования. Поскольку при этом возникают разные проблемы, они будут рассмотрены по от-