1526

Глава 23

роль PUBLIC выполнять UPDATE T непосредственно, без использования каких-либо ролей.

Устанавливается и поддерживается зависимость процедуры от объектов, на которые она ссыпается. Если процедура выполняет оператор SELECT FROM T, регистрируется зависимость процедуры от таблицы Т.

Если, например, создается процедура P, пытающаяся выполнить оператор SELECT * FROM T, компилятор сначала преобразует T в полностью уточненное имя. Имя T в базе данных неоднозначно - таких таблиц представлений может быть несколько. Чтобы в1-яснить, какую именно таблицу T использовать, сервер Oracle применяет правила определения области действия. Вместо синонимов подставляются соответствующие базовые объекты, причем для каждого объекта указывается имя соответствующей схемы. Это разрешение имен выполняется для текущего зарегистрированного пользователя (создателя). Другими словами, сервер ищет объект T у данного пользователя и использует его (при этом используются приватные синонимы пользователя), затем сервер ищет T среди общедоступных синонимов и т.д.

Определив объект, на который ссылается имя T, сервер Oracle определяет, возможен ли доступ к этому объекту в нужном режиме. В данном случае, если объект T принадлежит создателю процедуры или создатель непосредственно получил привилегию SELECT на объект T (или эта привилегия была предоставлена роли PUBLIC), процедура будет скомпилирована. Если создатель процедуры не имеет доступа к объекту по имени T благодаря непосредственно предоставленной привилегии, процедура P не будет скомпилирована. Таким образом, когда объект (хранимая процедура, ссылающаяся на T) компилируется, сервер Oracle выполняет все эти проверки. Если они пройдены , сервер Oracle компилирует процедуру, сохраняет двоичный код процедуры и устанавливает зависимости между этой процедурой и объектом Т. Эта зависимость используется для проверки действительности процедуры в дальнейшем, если что-то произошедшее с объектом T может потребовать перекомпиляции процедуры. Например, если позже мы выполним REVOKE SELECT ON T и отберем эту привилегию у владельца процедуры, сервер Oracle пометит все хранимые процедуры этого пользователя, зависящие от объекта T и сс1лающиеся на T, как недействительные (INVALID). Если мы добавим столбец с помощью оператора ALTER T ADD сервер Oracle сделает недействительными все зависящие от него процедуры. Это приведет к их автоматической перекомпиляции при следующем вызове.

Интересно разобраться не только в том, что сохраняется, но и что не сохраняется при компиляции объекта. Сервер Oracle не сохраняет информацию о привилегии, необходимой для получения доступа к объекту Т. Мы знаем только, что процедура P зависит от Т. Мы не знаем, почему получен доступ к объекту T:

потому что создателю процедуры была предоставлена соответствующая привилегия (GRANT SELECT ON T TO USER);

потому что привилегия была предоставлена роли PUBLIC (GRANT SELECT ON T TO PUBLIC);

потому что пользователь имеет привилегию SELECT ANY TABLE.

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

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

Теперь, когда процедура скомпилирована и хранится в базе данных, а все зависимости учтены, можно выполнять процедуру, точно зная, что представляет собой объект T, и будучи уверенными, что он доступен. Если что-то способное повлиять на доступность объекта T произойдет с самим объектом T или с набором базовых привилегий создателя процедуры, процедура станет недействительной и ее придется перекомпилировать.

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

Теперь нам предстоит разобраться, почему при компиляции и выполнении хранимых процедур с правами создателя роли не учитываются. Сервер Oracle не хранит информацию о том, почему мы можем обращаться к объекту T, - только то, что мы это можем. Любое изменение привилегий, которое может сделать невозможным обращение к объекту T, приведет к пометке процедуры как недействительной и ее перекомпиляции. Если роли не учитываются, такое изменение привилегий может произойти только при выполнении операторов REVOKE SELECT ANY TABLE или REVOKE SELECT ON T для пользователя-создателя или роли PUBLIC.

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

Рассмотрим результат лишения роли системной привилегии. Это будет аналогично лишению роли PUBLIC мощной системной привилегии (не делайте этого, просто представьте, а если уж хотите сделать, то в тестовой базе данных). Если роли PUBLIC была предоставлена привилегия SELECT ANY TABLE, в результате лишения ее этой привилегии будут помечены как недействительные практически все процедуры в базе данных. Если процедуры зависят от ролей, любая процедура в базе данных затрагивается даже наименьшими изменениями прав доступа. Поскольку одно из основных преимуществ хранимых процедур - однократная компиляция при многократном выполнении, это крайне негативно повлияет на производительность.

Учтите также следующие особенности ролей.

Роли могут бтть нестандартн1ми. Если я создам нестандартную роль, включу ее и скомпилирую процедуру, работа которой зависит от привилегий этой роли, по завершении сеанса у меня этой роли больше не будет. Станет ли при этом процедура недействительной? Почему? А почему - нет? Я легко могу обосновать оба варианта.

Роли могут б1ть защищен! паролями. Если изменен пароль роли, надо ли перекомпилировать все объекты, которым эта роль может понадобиться? Мне эта роль может быть предоставлена, но, не зная ее нового пароля, я не смогу ею восполь-

1528

Глава 23

зоваться. Будут ли по-прежнему доступны соответствующие привилегии? Почему - да или почему - нет? Есть аргументы и за, и против.

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

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

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

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

Права вызывающего

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

Рассмотрим две части процедур, работающих с правами вызывающего:

SQL-части - все операторы SELECT, INSERT, UPDATE, DELETE и все операторы, динамически выполняемые с помощью DBMS SQL или EXECUTE IMMEDIATE (включая динамически выполняемый PL/SQL-код);

PL/SQL-части - статические ссылки на объектные типы в объявлениях переменных, вызовы хранимых процедур, пакетов, функций и т.п.

В процедурах с правами вызывающего обработка этих частей очень отличается. Имена в SQL-части разрешаются при компиляции (для определения структур данн1х и т.п.) и еще раз - при выполнении. Именно это позволяет хранимой процедуре с запросом SELECT * FROM ЕМР обращаться к другим таблицам ЕМР при выполнении другими пользователями. Однако PL/SQL-части при компиляции связываются статически, как