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

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

AUTHID CURRENT USER as

begin

for x in (select * from T) loop proc(x.cl);

end loop;

то ссылки на T будут разрешаться во время выполнения (как и во время компиляции, чтобы понять, что означает SELECT *) динамически, что позволяет использовать раз-н1е объекты T для каждого пользователя. Ссылка на процедуру PROC, однако, будет разрешена только при компиляции, поэтому процедура будет статически связана с одной процедурой PROC. Пользователю, вызывающему эту процедуру, не нужна привилегия EXECUTE ON PROC, но вот привилегия SELECT для объекта T нужна. Не хочется вас запутывать, но если необходимо разрешать вызов PROC при выполнении, есть механизм и для этого. Можно написать следующий код:

AUTHID CORRENT USER

begin

for x in (select * from T) loop

execute immediate begin proc(:x); end; USING x.cl;

end loop;

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

Разрешение ссылок и передача привилегий

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

непосредственный вызов пользователем;

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

вызов из другой процедуры с правами вызывающего;

вызов из SQL-оператора;

вызов из представления, ссылающегося на процедуру с правами вызывающего;

вызов из триггера.

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

1530

Глава 23

Начнем с изучения того, как связываются объекты и какие привилегии доступны в процедуре с правами вызывающего при выполнении в каждой из перечисленных сред. Случаи представления и триггера будем считать одинаковыми, поскольку там процедура может работать только с правами создателя. Кроме того, поскольку статические объекты PL/SQL всегда, во всех средах разрешаются во время в1полнения, мы их рассматривать не будем. Они всегда разрешаются в схеме и с привилегиями создателя. Текущему зарегистрированному пользователю не нужен доступ к объекту PL/SQL, на котор1й делается ссылка. В следующей таблице описано предполагаемое поведение в каждой из сред:

Среда

SQL-объекты и динамически вызываемый PL/SQL

Роли действуют?

Непосредственный вызов

пользователем. Например: SQL> exec p;

Вызов из процедуры с правами создателя (P1), где P2 -процедура с правами вызывающего. Например: procedure p1 is

begin p2;

end;

Ссылки на эти объекты разрешаются в стандартной схеме и со стандартными привилегиями текущего пользователя. Неуточненные ссылки на объекты будут разрешаться в их схеме. Все объекты должны быть доступны текущему зарегистрированному пользователю. Если процедура выполняет SELECT из T, текущий пользователь также должен иметь привилегию SELECT для объекта T (полученную либо непосредственно, либо через роль).

Да. Все роли, включенные до выполнения процедуры, действуют и в процедуре. Они будут использоваться для разрешения или запрещения доступа ко всем SQL-объемам и динамически вызываемому PSQL-коду.

Этот вызов разрешается в схеме создателя, в схеме вызывающей процедуры. Неуточненные имена объектов будут разрешаться в этой схеме, схеме вызывающей процедуры, а не в схеме текущего зарегистрированного пользователя и не в схеме, где была создана процедура с правами вызывающего, В нашем примере, владелец P1 всегда будет вызывающим внутри процедуры P2.

Нет. Роли не учитываются, поскольку вызвана процедура с правами создателя. В момент входа в процедуру с правами создателя все роли отключаются и не учитываются до выхода из этой процедуры,

Вызов из другой процедуры с правами вызывающего.

Вызов из

SQL-оператора.

Аналогично непосредственному вызову пользователем.

Аналогично непосредственному вызову пользователем.

Да. Точно так же, как и при вызове пользователем,

Да. Точно так же, как и при вызове пользователем.

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

1531

Среда

SQL-объекты и динамически вызываемый PL/SQL

Роли действуют?

Вызов из представления или триггера, ссылающегося на процедуру с правами вызывающего.

Аналогично вызову из с правами создателя.

процедуры Нет. Точно так же, как и при вызове из процедуры с правами создателя.

Как видите, среда выполнения может существенно влиять на выполнение процедуры с правами вызывающего. Одна и та же хранимая процедура на PL/SQL при непосредственном вызове и при вызове из другой хранимой процедуры может обращаться к различным наборам объектов, даже при регистрации от имени одного и того же пользователя.

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

drop user a cascade;

tkyte@TKYTE816> User dropped. tkyte@TKYTE816> User dropped. tkyte@TKYTE816>

drop user b cascade;

create user a identified by a default tablespace data

temporary tablespace temp; User created.

tkyte@TKIE816> grant connect, resource to a; Grant succeeded.

tkyte@TK[E816> create user b identified by b default tablespace data temporary tablespace temp;

User created.

tkyte@TKE816> grant connect, Grant succeeded.

resource to b;

Итак, созданы два пользователя, А и В, и каждому из них предоставлены две роли, CONNECT и RESOURCE. Пользователь А создаст процедуру с правами вызывающего, а также процедуру с правами создателя и представление, из которых будет вызываться процедура с правами вызывающего. При каждом выполнении процедура будет выдавать количество действующих ролей, имя текущего пользователя (с набором привилегий какой схемы она работает), имя текущей схемы и, наконец, какая таблица используется запросом. Начнем с создания таблицы, определенно принадлежащей пользователю А: