Владелец Объекта Базы Данных

Владелец объекта базы данных

Пользователь, создавший объект базы данных, становится его владельцем.Только владелец объекта и пользователи с правами администратора в базе данных могут изменить или удалить объект базы данных.Владелец базы данных, то есть пользователь, который создал её, имеет все права на объекты, которые были созданы другими пользователями.

Администраторы или владелец объекта могут выдавать привилегии другим пользователям, в том числе и привилегии на право выдачи привилегий другим пользователям.Собственно сам процесс раздачи и отзыва привилегий на уровне SQL реализуется двумя операторами: GRANT, REVOKE.

Привилегии выполнения SQL кода

Все объекты метаданных содержащие DML или PSQL код могут выполняться в одном из следующих режимов:

С привилегиями вызывающего пользователя (привилегии CURRENT_USER);
С привилегиями определяющего пользователя (владельца объекта метаданных).

Исторически сложилось, что все PSQL модули по умолчанию выполняются с привилегиями вызывающего пользователя.Начиная с Firebird 4.0 появилась возможность указывать объектам метаданных с какими привилегиями они будут выполняться: вызывающего или определяющего пользователя.Для этого используется предложение SQL SECURITY, которое можно указать для таблицы, триггера, процедуры, функции или пакета.Если выбрана опция INVOKER, то объект метаданных будет выполняться с привилегиями вызывающего пользователя.Если выбрана опция DEFINER, то объект метаданных будет выполняться с привилегиями определяющего пользователя (владельца). Эти привилегии будут дополнены привилегиями выданные самому PSQL модулю с помощью оператора GRANT.

Привилегии выполнения, с которым по умолчанию (не указано у самого модуля) выполняется любой PSQL модуль можно изменить с помощью оператора

ALTER DATABASE SET DEFAULT SQL SECURITY {DEFINER | INVOKER}

Для сохранения обратной совместимости по умолчанию используется опция INVOKER.

Note

Замечания

Представления (VIEWs) всегда выполняются с привилегиями определяющего пользователя (владельца);
По умолчанию триггеры наследуют привилегии выполнения которые были указаны у таблицы. Привилегии выполнения могут быть переопределены в самом триггере;
Процедуры и функции пакета всегда наследуют привилегии выполнения указанный при определении пакета. Привилегии выполнения не могут быть переопределены в самих процедурах и функция пакета;
Анонимные PSQL блоки (EXECUTE BLOCK) всегда выполняются с правами вызывающего пользователя.

В хранимых процедурах, функциях и триггерах вы можете проверить эффективного в настоящий момент пользователя, т.е.пользователя с привилегиями которого выполняется текущий модуль, с помощью системной контекстной переменной EFFECTIVE_USER из пространства имён SYSTEM.

select RDB$GET_CONTEXT('SYSTEM', 'EFFECTIVE_USER') from RDB$DATABASE;

Note

Один и тот же объект может вызываться в разных контекстах безопасности и требовать различных привилегий.Например, у нас есть:

хранимая процедура INV с SECURITY INVOKER, которая вставляет записи в таблицу T;
хранимая процедура DEF с SQL SECURITY DEFINER, которая определена пользователем SYSDBA.

Если пользователь U вызывает процедуру INV, то для доступа к таблице T потребуется привилегия INSERT выданная пользователю U (и конечно привилегия EXECUTE для INV). В этом случае U является эффективным пользователем (EFFECTIVE_USER) во время выполнения INV.

Если пользователь U вызывает процедуру DEF, то для доступа к таблице T потребуется привилегия INSERT выданная пользователю SYSDBA (и EXECUTE на DEF для пользователя U). В этом случае SYSDBA является эффективным пользователем (EFFECTIVE_USER) во время выполнения DEF.Если внутри DEF вызывается процедура INV, то эффективным пользователем по время выполнения INV будет так же SYSDBA.