1514 Глава 23

34 /

Procedure created.

utils acct@TKYTE816> grant execute on print table to public; Grant succeeded.

Теперь я пойду на шаг дальше: сделаю так, чтобы от имени учетной записи UTILSACCT зарегистрироваться вообще было невозможно. Это предотвратит подбор пользователем пароля учетной записи UTILSACCT и размещение троянского кода под видом процедуры PRINTTABLE. Конечно, администратор базы данных с соответствующими привилегиями сможет снова активизировать эту учетную запись и зарегистрироваться от имени UTILSACCT - этого предотвратить нельзя:

utils acct@TKYTE816>connecttkyte/tkyte

tkyte@TKYTE816> revoke create session, create procedure 2 from utils acct;

Revoke succeeded.

Итак, имеется учетная запись, в схеме которой хранится код, но она по сути заблокирована, поскольку больше не имеет привилегии CREATE SESSION. При регистрации от имени пользователя SCOTT оказывается, что мы не только по-прежнему можем использовать эту процедуру (хотя учетная запись UTILS ACCT лишена всех привилегий), но и обращаться к своим таблицам. Убедимся, что другие пользователи не могут использовать эту процедуру для доступа к нашим таблицам (если только они не сделают это непосредственно, с помощью запроса), т.е. продемонстрируем, что процедура работает с привилегиями вызывающего:

scott@TKYTE816> exec utils acct.print table(select * from scott.dept )

DEPTNO : 10

DNAME : AGGOUNTING

LOG : NEW YORK

PL/SQL procedure successfully completed.

Это показывает, что пользователь SCOTT может использовать процедуру, и она имеет доступ к объектам в схеме пользователя SCOTT. Однако при выполнении от имени пользователя ANOTHER USER обнаруживается следующее:

scott@TKYTE816> connect another user/another user

another user@TKYTE816>desc scott.dept ERROR:

ORA-04043 : object scott.dept does not exist another user@TKYTE816> set serverout on

another user@TKYTE816> exec utils acct.print table(select * from -> scott.dept) ;

BEGIN utils acct.print table(select * from scott.dept) ; END; *

ERROR at line 1 :

ORA-00942 : table or view does not exist

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

ORA-06512: at UTILS ACCT.PRINT TABLE ,line 31

ORA-06512: at line 1

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

another user@TKYTE816> connect scott/tiger

scott@TKYTE816> grant select on dept to another user;

Grant succeeded.

scott@TKYTE816> connect another user/another user

another user@TKYTE816> exec utils acct.print table(select * from scott.dept);

DEPTNO : 10

DNAME : ACCOUNTING

LOC : NEW YORK

PL/SQL procedure successfully completed.

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

Приложения, работающие со словарем данных

Разработчикам всегда хотелось создать процедуры, выдающие информацию из словаря данных в более удобном виде, чем можно получить с помощью простого оператора SELECT, или, например, средства получения операторов ЯОД. С помощью процедур, работающих с правами создателя, сделать это было очень сложно. Если используются представления USER * (например, USER TABLES), будет выдаваться информация об объектах, принадлежащих создателю процедуры, а не вызывающему. Дело в том, что в условиях всех представлений USER* и ALL * есть конструкция:

where o.owner# = userenv(SCHEMAID)

Функция USERENV(SCHEMAID) возвращает идентификатор пользователя для схемы, в которой выполняется процедура. В хранимой процедуре с правами создателя (т.е. в стандартной хранимой процедуре) это значение постоянно - это всегда будет идентификатор пользователя, в схеме которого создана процедура. Это означает, что если кто-то напишет процедуру, обращающуюся к словарю данных, эта процедура будет видеть его объекты, а не объекты пользователя, выполняющего запрос. Более того, в хранимой процедуре роли не используются (мы рассмотрим эту проблему чуть позже), так что, если доступ к таблице в схеме другого пользователя получен через роль, в хранимой процедуре эта таблица будет недоступна. Когда-то единственным решением было создание хранимой процедуры, обращающейся к представлениям DBA * (после получения непосредственн1х привилегий для этого) и реализующей собственный механизм защиты, который гарантировал получение пользователями только той информации,

1516

Глава 23

которая доступна им в представлениях ALL * или USER *. Это более чем нежелательно, поскольку приходится писать большой объем кода, предоставлять права доступа ко всем представлениям DBA *; кроме того, при малейшей невнимательности процедура позволит получить несанкционированный доступ к объектам.

Здесь поможет процедура, работающая с правами вызывающего. Теперь можно не только создать хранимую процедуру, обращающуюся к представлениям ALL * и USER *, - это можно делать от имени текущего зарегистрированного пользователя, c его привилегиями и даже ролями. Мы продемонстрируем это, реализовав усовершенствованную команду DESCRIBE. Это будет минимальная по возможностям реализация - разобравшись, как это работает, вы сможете добавить любые возможности:

tkyte@TKYTE816> create or replace

10 11 12 13

16 17

18 19 20 21 22

24 25 26 27 28

30 31

38 39

procedure desc table(p tname AUTHID GURRENT USER as

begin

dbms output.put line(TMna dbms output.new line;

in varchar2)

данных для таблицы p tname) ;

dbms output.put line(rpad(H столбца,31)

rpad(Тип данных,2 0)

rpad(Длинa,11)

Пустые значения); dbms output.put line(rpad(-\30,-) rpad(-,19,-)

rpad(-,10,-)

- ) ;

for x in

(select column name, data type, substr(

decode(data type,

NUMBER, decode(data precision, NULL, NULL,

(data precision,data scale)), data length),l,ll) data length, decode(nullable,Y,null,not null) nullable

from user tab columns where table name = upper(p tname) order by column id)

loop

dbms output.put line(rpad(x.column natne,31)

rpad(x.data type,20)

rpad(x.data length,ll) x.nullable);

end loop;

dbms output.put line(chr(10)

Индексы

chr(10)

по p tname);

for z in

(select a.index name,

a.unieness