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

1517

41 42 43 44 45 46 47 48 49 50 51 5 2 53

55 56

57 58

59 60

- upper(p tname) NORMAL)

from user indexes where a.table name and index type -

loop

dbms output.put(rpad(z.index name,31)

z.uniqueness);

for y in

(selectdecode(column position,l,(, )

column name column name

from user ind columns b where b.index name = z.index name order by column position)

loop

dbms output.put(y.column name); end loop;

dbms output.put line(1) II chr(10)); end loop;

end;

Procedure created.

tkyte@TKYTE816> grant execute 2 /

Grant succeeded.

on desc table to public

Эта процедура интенсивно обращается к представлениям USER INDEXES и USER IND COLUMNS. При работе с правами создателя (без конструкции AUTHID CURRENT USER) эта процедура сможет вьдать информацию только для одного пользователя (и всегда - для одного и того же). Однако при использовании прав вызывающего процедура будет выполняться от имени и с привилегиями пользователя, зарегистрировавшегося во время выполнения. Так что, хотя процедура и принадлежит пользователю TK, ее можно выполнять от имени пользователя SCO и получать результат, подобный следующему:

1518 Глава 23

Индексы по emp

EMP PK UNIQUE(EMPNO)

PL/SQL procedure successfully completed.

Универсальные объектные типы

Идея в данном случае та же, что и в предыдущем, но результаты могут быть более общезначимыми. С помощью средств Oracle 8, позволяющих создавать собственные объектные типы со специфическими методами обработки данных, можно создавать методы, работающие с набором привилегий текущего зарегистрированного пользователя. То есть, создав универсальные, обобщенные типы, их устанавливают в базе данн1х один раз и разрешают всем использовать. Без возможности работать с правами в]з1вающего владелец объектного типа должен был иметь очень мощные привилегии (как было описано ранее) или надо было устанавливать этот объектный тип в каждой схеме, где его предполагалось использовать.

Именно с правами вызывающего всегда работали объектные типы, стандартно поставляемые в составе сервера Oracle (например, типы ORDSYS.*, используемые для поддержки компонентов interMedia), что позволяло устанавливать их в базе данных только один раз, а использовать - любому пользователю со своими привилегиями. Это имеет значение, потому что объектные типы ORDSYS выполняют чтение и запись в таблицы базы данных. Набор таблиц, к которым они обращаются, полностью зависит от того, кто именно выполняет соответствующие методы. Именно это свойство позволяет обеспечить универсальность и общедоступность этих типов. Они устанавливаются в схеме ORDSYS, но пользователь ORDSYS не имеет доступа к таблицам, с которыми они фактически работают. Теперь, используя Oracle 8i, разработчики приложений могут создавать такие же типы.

Реализация собственных средств контроля доступа

В Oracle 8i появилась возможность тщательного контроля доступа (Fine Grained Access Control - FGAC), благодаря чему можно реализовать правила защиты, предотвращающие несанкционированный доступ к данным. Обычно для этого в каждую таблицу добавляется столбец, например COMPANY. Значения в этом столбце автоматически формируются триггером, а в каждый запрос включается условие WHERE COMPANY = SYS CONTEXT (...), ограничивающее набор доступных пользователю строк только теми, доступ к которым авторизован (подробнее об этом см. в главе 21).

Можно также создавать отдельную схему (набор таблиц) для каждой компании. Другими словами, для каждой компании устанавливается и наполняется данными свой набор таблиц. При этом в принципе невозможен доступ одного пользователя к данн1м другого, поскольку данные эти физически хранятся в другой таблице. Это - вполне уместный подход, имеющий преимущества (и недостатки) по сравнению со средствами тщательного контроля доступа. Проблема, однако, в том, что хотелось бы поддерживать один набор хранимого кода для всех пользователей. Кэширования же в разделяемом пуж

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

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

Имея возможность работать с правами вызывающего, можно написать одну хранимую процедуру, обращающуюся к таблицам с правами доступа текущего пользователя и разрешением имен в его схеме. Как было продемонстрировано в примере с процедурой PRINT TABLE, это можно сделать как с помощью динамического, так и статического SQL Рассмотрим следующий пример. Установим таблицы EMP/DEPT в схеме SCO и в моей схеме TKYTE. Третий пользователь будет создавать приложение, использующее таблицы ЕМР и DEPT для создания отчета; он не будет иметь доступа к таблицам ЕМР и DEPT ни в схеме SCOTT, ни в схеме TKYTE (его таблицы созданы для тестирования). Вы увидите, что процедура, выполненная пользователем SCO, будет выдавать данные из схемы SCOTT; когда же ее выполнит пользователь TKYTE, будут использованы таблицы последнего:

tkyte@TKYTE816> connect scott/tiger scott@TKYTE816> grant select on emp to public; Grant succeeded.

scott@TKYTE816> grant select on dept to public; Grant succeeded.

scott@TKYTE816> connect tkyte/tkyte

tkyte@TKYTE816> create table dept as select * from scott.dept; Table created.

tkyte@TKYTE816> create table emp as select * from scott.emp; Table created.

tkyte@TKYTE816> insert into emp select * from emp; 14 rows created.

tkyte@TKYTE816> create user application identified by pw

2 default tablespace users quota unlimited on users;

User created.

tkyte@TKYTE816> grant create session, create table, 2 create procedure to application;

Grant succeeded.

tkyte@TKYTE816> connect application/pw

application@TKYTE816> create table emp as select * from scott.emp where 1=0; Table created.

application@TKYTE816> create table dept as

2 select * from scott.dept where 1=0;

Table created.