Если у вас есть привилегия SET_ANY_DEFINER, вы можете указать любую учетную запись в качестве атрибута DEFINER. Если учетная запись не существует, генерируется предупреждение. Кроме того, чтобы установить атрибут хранимого объекта DEFINER на учетную запись, имеющую привилегию SYSTEM_USER, вам необходимо иметь привилегию SYSTEM_USER.

В противном случае единственная разрешенная учетная запись — ваша собственная, указанная либо явно, либо как CURRENT_USER или CURRENT_USER(). Вы не можете установить для определённого объекта другой пользователь.

Хранимый объект, выполняемый в контексте безопасности пользователя-определяющего, выполняется с привилегиями учетной записи, указанной в его атрибуте DEFINER. Эти привилегии могут полностью отличаться от привилегий вызывающего пользователя. Вызывающий пользователь должен иметь соответствующие привилегии для обращения к объекту (например, EXECUTE для вызова хранимой процедуры или SELECT для выборки из представления), но во время выполнения объекта привилегии вызывающего пользователя игнорируются, и учитываются только привилегии учетной записи DEFINER. Если учетная запись DEFINER имеет ограниченный набор привилегий, объект также ограничен в выполняемых операциях. Если учетная запись DEFINER имеет высокие привилегии (например, административная учетная запись), объект может выполнять мощные операции независимо от того, кто его вызывает.

Хранимая процедура или представление, выполняемая в контексте безопасности вызывающего пользователя, может выполнять только те операции, для которых вызывающий пользователь имеет привилегии. Атрибут DEFINER не оказывает влияния на выполнение объекта.

Хранимый объект-сирота может быть создан путём указания несуществующей DEFINER учётной записи во время создания объекта.

Существующий хранимый объект может стать сиротой в результате выполнения инструкции DROP USER, которая удаляет учётную запись объекта DEFINER, или инструкции RENAME USER, которая переименовывает учётную запись объекта DEFINER.

Поскольку учётная запись DEFINER не существует, объект может не работать должным образом, если он выполняется в контексте безопасности определяющего пользователя:

Объект может представлять собой угрозу безопасности, если несуществующая учётная запись DEFINER впоследствии будет создана с целью, не связанной с объектом. В этом случае учётная запись “усыновляет” объект и, имея соответствующие привилегии, может его выполнить, даже если это не предполагалось.

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

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

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

Чтобы определить, какие значения DEFINER существуют в каждой таблице, используйте эти запросы:

SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;

Результаты запроса важны для любой учётной записи, отображаемой следующим образом:

Чтобы переопределить объект с использованием другого определяющего пользователя, можно использовать ALTER EVENT или ALTER VIEW для непосредственного изменения учётной записи DEFINER событий и представлений. Для хранимых процедур и функций и триггеров необходимо удалить объект и создать его заново, чтобы назначить другую учётную запись DEFINER.

Чтобы определить, какие объекты имеют заданную учётную запись DEFINER, используйте эти запросы, заменив интересующую учётную запись на user_name@host_name:

SELECT EVENT_SCHEMA, EVENT_NAME FROM INFORMATION_SCHEMA.EVENTS
WHERE DEFINER = 'user_name@host_name';
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE DEFINER = 'user_name@host_name';
SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS
WHERE DEFINER = 'user_name@host_name';
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS
WHERE DEFINER = 'user_name@host_name';

Для таблицы ROUTINES запрос включает столбец ROUTINE_TYPE, чтобы строки вывода различали, является ли DEFINER хранимой процедурой или хранимой функцией.

Если учётная запись, которую вы ищете, не существует, все объекты, отображённые этими запросами, являются объектами-сиротами.

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

Для хранимой процедуры или представления, используйте SQL SECURITY INVOKER в определении объекта, когда это возможно, чтобы он мог быть использован только пользователями с правами, соответствующими операциям, выполняемым объектом.

Если вы создаете хранимые объекты контекста определённого пользователем при использовании аккаунта, обладающего правом SET_ANY_DEFINER, укажите явный атрибут DEFINER, который назначает аккаунт, обладающий только необходимыми для выполняемых объектом операций правами. Указывайте высокопривилегированный аккаунт DEFINER только в том случае, если это абсолютно необходимо.

Администраторы могут предотвратить создание пользователями хранимых объектов, которые указывают высокопривилегированные аккаунты DEFINER, не предоставляя им право SET_ANY_DEFINER.

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

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

В обоих случаях, если аккаунт DEFINER имеет высокие привилегии, объект может выполнять конфиденциальные или опасные операции. Это остается справедливым, даже если права, необходимые для создания объекта, отозваны у учётной записи пользователя, который его создал. Администраторы должны быть особенно внимательны при предоставлении пользователям прав на создание объектов.

По умолчанию, при выполнении процедуры с характеристикой SQL SECURITY DEFINER, сервер MySQL не устанавливает активные роли для учётной записи MySQL, указанной в предложении DEFINER, а только роли по умолчанию. Исключением является случай, когда переменная системы activate_all_roles_on_login включена, в этом случае сервер MySQL устанавливает все роли, предоставленные пользователю DEFINER, включая обязательные роли. Следовательно, по умолчанию любые привилегии, предоставленные через роли, не проверяются при выполнении операторов CREATE PROCEDURE или CREATE FUNCTION. Для хранимых программ, если выполнение должно происходить с ролями, отличными от по умолчанию, тело программы может выполнить SET ROLE для активации необходимых ролей. Это следует делать с осторожностью, так как привилегии, назначенные ролям, могут быть изменены.