Если у вас есть привилегия 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 Server не устанавливает активные роли для учётной записи MySQL, указанной в предложении DEFINER, устанавливаются только роли по умолчанию. Исключением является случай, когда системная переменная activate_all_roles_on_login включена, в этом случае MySQL Server устанавливает все роли, предоставленные пользователю DEFINER, включая обязательные роли. Следовательно, любые привилегии, предоставленные через роли, по умолчанию не проверяются при выполнении оператора CREATE PROCEDURE или CREATE FUNCTION. Для хранимых программ, если необходимо выполнение с ролями, отличными от стандартных, тело программы может выполнить SET ROLE для активации требуемых ролей. Это следует делать с осторожностью, так как привилегии, назначенные ролям, могут быть изменены.