Как предоставить SELECT для любой таблицы в схеме на роль (Oracle)

Question

Мы хотим создать роль ANALYTICS в нашей базе данных Oracle. Любой, кто находится в этой роли АНАЛИТИКА, должен иметь возможность ВЫБРАТЬ среди любых представлений в одной (или более) схемах, но не ВСЕХ схем.

Например, у нас есть схема с именем ARIEL, и когда мы создаем новые таблицы и представления, нам не нужно постоянно применять GRANTS к роли ANALYTICS, и поэтому мы надеемся, что есть способ применить грант например, «ВЫБРАТЬ ГРАНТ ДЛЯ ВСЕХ ТАБЛИЦ В SCHEMA_X ДЛЯ АНАЛИТИКИ» ... примечание АНАЛИТИКА - это роль, а не схема.

Наш администратор БД говорит, что это невозможно, и на любые будущие объекты, которые мы создадим, потребуется применить грант, дающий доступ к РОЛЕ.

Answer 1

«Наш администратор БД говорит, что это невозможно, и на любые будущие объекты, которые мы создадим, потребуется применить грант, дающий доступ к РОЛЕ.»

Ваш администратор БД правильный,Вы ищете широкие привилегии схемы (еще не реализовано).

Дополнительно: GRANT SELECT для всех таблиц в схеме

Answer 2

Ваш администратор базы данных прав, что для каждого создаваемого объекта потребуется грант. Это можно автоматизировать, что дает вам в основном то поведение, которое вы хотите. Я делал это в прошлом. Но я бы серьезно усомнился в этом требовании перед его выполнением.

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

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

• Создать триггер DDL, который срабатывает при создании таблицы
• В этом триггере DDL используйте dbms_job, чтобы выполнить оператор предоставления сразу после того, как оператор CREATE TABLE подтвердит

Нечто подобное должно работать (не проверено)

CREATE OR REPLACE TRIGGER ddl_create
   AFTER CREATE ON SCHEMA
DECLARE
   l_job         BINARY_INTEGER;
   l_sql         VARCHAR2(4000);
BEGIN
   IF ora_dict_obj_type = 'TABLE' 
  THEN
      l_sql := 'grant select on ' ||
                 ora_dict_obj_owner || '.' || ora_dict_obj_name ||
                 ' to analytics';

      DBMS_JOB.SUBMIT (
          job => l_job,
         what => l_sql );
   END IF;
END;

Поскольку задание выполняется асинхронно, возможно, для запуска после создания таблицы потребуется секунда или две, что может быть проблемой, если приложение немедленно попытается выполнить запрос к объекту. Также возможно, что ваш администратор базы данных может отключить задания или ограничить количество заданий, которые могут выполняться одновременно, что может еще больше задержать предоставление. И если что-то пойдет не так с триггером или работой, это достаточно непонятный подход, и людям потребуется время, чтобы выяснить, в чем проблема. Администраторы баз данных не имеют привычки искать триггеры DDL, которые могут предоставлять привилегии, когда кто-то решает, скажем, что он хочет, чтобы новая роль автоматически получала доступ insert к новой таблице или когда грант не выполнялся, потому что задания были отключены.