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

Часто разработчики спрашивают: Как сделать так, чтобы только мое приложение, myapp.exe, могло выполнять действие X в базе данных? . Например, надо, чтобы это приложение могло выполнять вставку в таблицу, но другие приложения этого сделать не могли. Единственно безопасн1й способ сделать это - поместить алгоритмы работы с дан-н1ми приложения myapp.exe в базу данных, и никаких операторов INSERT, UPDATE, DELETE или SELECT в клиентском приложении. Разместив приложение непосредственно в базе данных, устранив необходимость выполнять вставку (или любые другие операции с таблицей) в клиентском приложении, вы добьетесь того, чтобы только одно приложение могло обращаться к данным. Размещая алгоритмы работы с базой данных приложения в ней самой, мы делаем из приложения просто еще одни уровень абстракции. Не имеет значения, как вызывается приложение (его компонент, работающий с базой данных) - из SQL*Plus, из графического интерфейса или из другого, еще нереализованного интерфейса, - в базе данных работает одно и то же приложение.

Как работают процедуры с правами вызывающего

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

Права создателя

При использовании прав создателя хранимая процедура компилируется с учетом привилегий, непосредственно предоставленных пользователю, владеющему процедурой. Под непосредственно предоставленными привилегиями подразумеваются все объектные и системные привилегии, предоставленные пользователю или роли PUBLIC, но не другим ролям, которые предоставлены пользователю или роли PUBLIC. Короче, для процедур с правами создателя роли не учитываются и не используются, ни во время компиляции, ни при выполнении. Процедура компилируется только с учетом непосред-ственн1х привилегий. Это описано в руководстве OracleApplication Developers Guide тик:.

Привилегии, необходимые для создания процедур и функций

При создании отдельной процедуры или функции, спецификации или тела пакета должны выполняться следующие требования.

Необходимо наличие системной привилегии CREATE PROCEDURE (для создания процедуры или пакета в своей схеме) или системной привилегии CREATE ANY PROCEDURE (для создания процедуры или пакета в другой пользовательской схеме).

Внимание: Для успешной компиляции процедуры или пакета требуются следующие дополнительные привилегии:

владелец процедуры или пакета должен явно получить необходимые объектные привилегии для всех объектов, на которые есть ссылки в коде;

1524

Глава 23

владелец не может получить необходимые привилегии через роли.

Если привилегии владельца процедуры или пакета изменяются, процедуру необходимо повторно аутентифицировать перед выполнением. Если необходимая для доступа к объекту привилегия у владельца процедуры (или пакета) отобрана, выполнение процедуры становится невозможным.

Хотя это явно и не сказано, предоставление привилегии роли PUBLIC ничуть не хуже, чем непосредственно владельцу процедуры. Необходимость непосредственного предоставления привилегий владельцу процедуры, работающей с правами создателя, иногда приводит к странным ситуациям. Оказывается, можно выполнить запрос к объекту в SQL*Plus и использовать анонимный блок доступа к этому же объекту, но нельзя создать хранимую процедуру для обращения к этому объекту. Зададим необходимые для данного примера привилегии:

scott@TKYTE816> revoke select on emp from public-Revoke succeeded.

scott@TKYTE816> grant select on emp to connect; Grant succeeded.

scott@TKYTE816> connect tkyte/tkyte

tkyte@TKYTE816> grant create procedure to another user; Grant succeeded.

А теперь убедимся, что пользователь ANOTHERUSER может делать запросы к таблице SCOTT.EMP:

tkyte@TKYTE816> connect another user/another user

another user@TKYTE816> select count(*) from scott.emp; GOUNT(*)

Пользователь ANOTHER USER также может выполнять анонимный блок PL/SQL:

another user@TKYTE816> begin

2 for x in (select count(*) cnt from scott.emp)

3 loop

4 dbms output.put line(x.cnt);

5 end loop;

6 end;

PL/SQL procedure successfully completed.

Однако при попытке создать процедуру, идентичную представленному выше PL/SQL-блоку, мы получим следующее:

another user@TKYTE816> create or replace procedure P 2 as

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

3 begin

4 for x in (select count(*) cnt from scott.emp)

5 loop

6 dbms output.put line(x.cnt);

7 end loop;

8 end;

Warning: Procedure created with compilation errors . another user@TKYTE816> show err

Errors for PROCEDURE P:

LINE/COL ERROR

4/14 PL/SQL: SQL Statement ignored

4/39 PLS-00201: identifier SCOTT.EMP must be declared

6/9 PL/SQL: Statement ignored

6/31 PLS-00364: loop index variable X use is invalid

Я не могу создать процедуру (собственно, любой скомпилированный хранимый объект, скажем, представление или триггер), обращающуюся к таблице SCOTT.EMP. Это предсказуемая и описанная в документации особенность. В рассмотренном выше

примере пользователь ANOTHER USER имеет роль CONNECT. Роли CONNECT была

предоставлена привилегия SELECT для таблицы SCOTT.EMP. Эта привилегия роли CONNECT, однако, недоступна в хранимой процедуре с правами создателя, поэтому и в]дается сообщение об ошибке. Чтобы избежать таких странностей, я рекомендую выполнить оператор SET ROLE NONE в среде SQL*Plus и попытаться выполнить оператор, который предполагается включить в хранимую процедуру. Например:

another user@TKYTE816> set role none;

Role set.

another user@TKYTE816> select count(*) from scott.emp;

select count(*) from scott.emp

ERROR at line 1:

ORA-00942: table or view does not exist

Если оператор сработает в SQL*Plus без ролей, он, несомненно, сработает и в хранимой процедуре, выполняющейся с правами создателя.

Компиляция процедуры с правами создателя

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

Проверяется существование всех объектов, к которым процедура обращается статически (всех, к которым не обращаются с помощью динамического SQL). Имена разрешаются с помощью стандартных правил области действия по отношению к владельцу процедуры.

Проверяется, все ли объекты доступны в нужном режиме. Например, если выполняется оператор UPDATE T, сервер Oracle проверит, может ли создатель или