Права в1зывающего и создателя 1553

ul@TKYTE816> exec tkyte.dr dr java

Зто таблица Т, принадлежащая пользователю TKYTE session user=U1 current user=TKYTE current schema =TKYTE

PL/SQL procedure successfully completed. Разумеется, она выполняется с правами создателя.

Вы можете даже не заметить, что хранимая Java-процедура загружается с правами вызывающего, поскольку вызывается она обычно из PL/SQL-подпрограмм, а они стандартно компилируются с правами создателя. Обычно Java-код загружается в ту же схему, где создается спецификация вызова; и если она создана с правами создателя, Java-код также работает с правами создателя. Я возьму на себя смелость предположить, что большинство пользователей не подозревает о такой особенности загрузки Java-кода, поскольку по результатам почти никогда нельзя догадаться о работе с правами вызывающего. Только если спецификация вызова на PL/SQL создана с конструкцией AUTHID CURRENT USER, это свойство может проявиться.

Еще одни случай, когда стандартная загрузка Java-кода с правами вызывающего имеет значение, - создание спецификации вызова не в той схеме, в которой загружен байт-код Java. Используя тот же загруженный ранее Java-код, я создал от имени пользователя U1 несколько спецификаций вызова Java-кода из схемы пользователя TKTE. Для этого пользователю U1 предоставлена привилегия CREATE PROCEDURE. Кроме того, используется тот факт, что при загрузке Java-кода задана опция -synonym, благодаря которой для загруженного кода создан общедоступный синоним, а также опция -grant U1, предоставившая пользователю U1 непосредственный доступ к Java-коду. Вот результат:

u1@TKYTE816> create OR replace procedure ir java

2 authid current user

3 as language java name ir java.test();

Procedure created. ul@TKYTE816>exec ir java

Зто таблица Т, принадлежащая пользователю U1 session user=Ul current user=U1 current schema=Ul

PL/SQL procedure successfully completed.

Вы видите, что процедура с правами вызывающего (процедура с правами создателя дала бы тот же результат), принадлежащая пользователю U1, выполняет SQL-операторы в Java-коде так, как если бы ее загрузил пользователь U1. Это свидетельствует о том, что Java-код загружен с правами вызывающего. В противном случае, SQL-оператор в Java-коде работал бы с разрешением имен и привилегиями пользователя TKTE, а не U1. Следующий пример показывает работу процедуры с правами создателя, созданной в схеме U1. Java-код работает от имени TKYTE:

ul@TKYTE816> create OR replace procedure dr java

2 as language java name dr java.test()1;

Procedure created.

1554

Глава 23

ul@TKYTE816> exec dr java

Это таблица Т, принадлежащая пользователю TKYTE session user=U1

current user=TKYTE current schema =TKYTE

PL/SQL procedure successfully completed.

Java-код, загруженный с правами создателя, работает от имени TKTE, а не U1. Загружать Java-код с правами создателя пришлось принудительно с помощью опции -del, поскольку свойства хранимых процедур на Java отличаются в этом отношении от свойств PL/SQL-процедур.

Возможные ошибки

Других специфических ошибок, кроме тех, что обсуждалось в разделе Проблемы , при использовании прав вызывающего или создателя не будет. Используя права вызывающего, важно четко понимать, как в PL/SQL обрабатываются встроенные SQL-опе-раторы, чтобы избежать проблем с операторами SELECT * и изменяющимся порядком столбцов, скрытыми столбцами при выполнении и так далее. Кроме того, работавший без проблем PL/SQL-код при использовании прав вызывающего может в]давать различные ошибки для каждого из пользователей. Причина в том, что ссылки на объекты разрешаются по-разному. В каких-то схемах может не хватать привилегий, использоваться другие типы данных и т.д.

При использовании прав вызывающего необходимо больше внимания уделять надежности кода- и учитывать возможность возникновения ошибок там, где их обычно не бывает. Статические ссылки больше не гарантируют безошибочность работы кода. Ситуация напоминает скорее создание ODBC- или JDBC-программы со встроенными непосредственными вызовами SQL-операторов. Вы контролируете компоновку программы (вам известно, какие подпрограммы в клиентском приложении будут вызываться), но вы не контролируете работу SQL-операторов до тех пор, пока они не в1полнят-ся. SQL-оператор в PL/SQL-подпрограмме с правами вызывающего работает также, как в клиентском приложении, использующем интерфейс JDBC. Не проверив все варианта: выполнения для каждого пользователя, вы не можете быть на 100 процентов уверены, что в производственной среде все будет работать без ошибок. Поэтому в коде надо больше заботиться об обработке ошибок, чем в традиционной хранимой процедуре.

Резюме

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

выявления и обработки ошибок;

трудно выявляемых ошибок, вызванных иной структурой таблицы при в1полне-

нии;

дополнительного расхода пространства в разделяемой области SQL;

дополнительных затрат времени на анализ операторов.

Права вызывающего и создателя 1555

Во многих случаях эта цена оказывается неприемлемой. В других же случаях (например, при создании универсальной подпрограммы для выдачи в виде набора строк со значениями столбцов через запятую результатов запроса или при форматировании результатов запроса по вертикали, а не по горизонтали) возможность использовать права вызывающего - бесценна. Без нее просто не удалось бы получить желаемый результат.

Подпрограммы с правами вызывающего имеет смысл применять в таких случаях:

когда необходимо использовать динамические SQL-операторы (как в упомянутых выше примерах);

когда выполняемые SQL-операторы обеспечивают защиту на базе идентификатора схемы (как в случае работы со словарем данных или при реализации собственных средств тщательного контроля доступа в приложении);

когда необходим учет ролей - только подпрограммы с правами вызывающего позволяют этого добиться.

Права вызывающего можно использовать для обеспечения доступа к различным схемам на основе текущей схемы, возвращаемой вызовом SYS CONTEXT(USERENV, CURRENT SCHEMA), но при этом надо позаботиться о согласованности схем и наличии необходимых привилегий (или учитывать возможные проблемы с этим в коде). Надо также быть готовым к более интенсивному использованию разделяемого пула и дополнительному расходу ресурсов сервера на анализ операторов.

Работа с правами создателя идеально подходит почти для всех хранимых процедур. Процедуры с правами вызывающего - мощное средство, но использовать его надо только по назначению.