Для начала представим ряд определений, чтобы гарантировать однозначное понимание терминов вызывающий и создатель:
• Создатель. Пользователь, создавший скомпилированный хранимый объект и владеющий им. (Говорят также, что объект находится в схеме пользователя.) К скомпилированным хранимым объектам относятся пакеты, процедуры, функции, триггеры и представления,
• Вызывающий. Пользователь, с привилегиями которого работает текущий сеанс. Это может быть текущий зарегистрированный пользователь, но может быть и другой пользователь.
До версии Oracle 8i все скомпилированные хранимые объекты выполнялись с правами создателя объекта. По отношению к соответствующей схеме происходило и разрешение имен. Другими словами, набор привилегий, непосредственно предоставленных владельцу (создателю) объекта использовался при компиляции для определения того:
• к каким объектам (таблицам и т.д.) фактически обращаться;
• есть ли у создателя необходимые для доступа к этим объектам привилегии.
Это статическое связывание, выполняемое на этапе компиляции, распространяется так далеко, что учитываются только непосредственно предоставленные создателю привилегии (другими словами, в ходе компиляции и выполнения хранимой процедуры роли не учитываются). Кроме того, при выполнении процедуры с правами создателя, она будет работать с базовым набором привилегий создателя, а не вызвавшего процедуру.
Начиная с Oracle 8i появилась возможность выполнять процедуры с правами вызывающего, что позволяет создавать процедуры, функции и пакеты, выполняющиеся с набором привилегий вызывающего, а не создателя.
Возможность выполнять код с правами вызывающего позволяет, например, создать хранимую процедуру, работающую с набором привилегий пользователя, который ее выполняет. В результате хранимая процедура может работать правильно и корректно для одного пользователя (который имеет доступ ко всем необходимым объектам), но не работать для другого (у которого такого доступа нет). Причина состоит в том, что доступ к базовым объектам проверяется не во время компиляции, а во время выполнения (правда, создатель должен иметь доступ к соответствующим объектам или хотя бы к объектам с такими же именами, чтобы PL/SQL-код вообще можно было скомпилировать).
Подобный доступ во время выполнения осуществляется с учетом привилегий и ролей текущего пользователя/схемы. Следует отметить, что работа с правами вызывающего не поддерживается для представлений и триггеров. Представления и триггеры создаются и работают только с правами создателя.
Необходимость работать с правами вызывающего чаще всего возникает, когда универсальный фрагмент кода создается одним пользователем, а используется - множеством других. Разработчик не имеет доступа к объектам, к которым будут иметь доступ пользователи. Именно привилегии пользователя будут определять, к каким объектам этот код может обращаться. Другая потенциальная причина использования прав вызывающего - необходимость создать набор процедур, централизованно выбирающих данные из нескольких различных схем. При использовании процедур, работающих с правами создателя, как было показано, привилегии и схема, относительно которой выполняется разрешение имен, - статичны и определяются во время компиляции. При каждом выполнении процедура, работающая с правами создателя, обращается к одному и тому же набору объектов (если, конечно, не используется динамическое формирование SQL-операторов). Работа с правами вызывающего позволяет создать процедуру, способную обращаться к аналогичным структурам в различных схемах, - в зависимости от того, кто ее вызвал.
Пусть создается хранимая процедура, использующая динамический SQL для выполнения запроса и выдачи результатов в виде файла со значениями через запятую. Если не работать с правами вызывающего, эта процедура будет универсальной и полезной всем только при выполнении одного из следующих условий.
• Создатель процедуры должен иметь возможность читать любой объект в базе данных. Например, обладать привилегией SELECT ANY TABLE. B противном случае при запуске этой процедуры для представления данных таблицы в виде текстового файла произойдет ошибка, потому что создатель не имеет необходимой привилегии SELECT для этой таблицы. Надо выполнять эту процедуру с правами вызывающего, а не создателя.
• Каждый пользователь должен иметь исходный код и устанавливать его копию в своей схеме. Это нежелательно по очевидным причинам - сопровождение превратится в кошмар. Если будет обнаружена ошибка в исходном коде или вследствие обновления версии придется изменять код, обновлять придется десятки копий. Кроме того, эта скопированная процедура все равно не может обращаться к объектам, доступным пользователю через роль.
Обычно именно второй вариант чаще всего применяется для разработки универсального кода. Этот подход неидеален, но более "безопасен" с точки зрения защиты данных. Используя работу с правами вызывающего, можно создать процедуру один раз, предоставить права на ее выполнение многим пользователям, и они будут использовать ее со своим набором привилегий и с разрешением имен в своих схемах.
Подпрограммы с правами вызывающего имеет смысл применять в таких случаях:
• когда необходимо использовать динамические SQL;
• когда выполняемые SQL-операторы обеспечивают защиту на базе идентифика-
тора схемы (как в случае работы со словарем данных или при реализации собственных средств тщательного контроля доступа в приложении);
• когда необходим учет ролей - только подпрограммы с правами вызывающего позволяют этого добиться.
Права вызывающего можно использовать для обеспечения доступа к различным схемам на основе текущей схемы, возвращаемой вызовом SYS_CONTEXT('USERENV','CURRENT_SCHEMA'), но при этом надо позаботиться о согласованности схем и наличии необходимых привилегий (или учитывать возможные проблемы с этим в коде).
Надо также быть готовым к более интенсивному использованию разделяемого пула и дополнительному расходу ресурсов сервера на анализ операторов.
Работа с правами создателя идеально подходит почти для всех хранимых процедур. Процедуры с правами вызывающего - мощное средство, но использовать его надо только по назначению.