## The DEFINER Attribute 

A stored object definition can include a DEFINER  attribute that names a MySQL account. If a definition omits the DEFINER  attribute, the default object definer is the user who creates it. 

The following rules determine which accounts you can specify as the DEFINER  attribute for a stored object: 

•If you have the SET_USER_ID  privilege (or the deprecated SUPER  privilege), you can specify any account as the DEFINER  attribute. If the account does not exist, a warning is generated. Additionally, to set a stored object DEFINER  attribute to an account that has the SYSTEM_USER  privilege, you must have the SYSTEM_USER  privilege. 

•Otherwise, the only permitted account is your own, specified either literally or as CURRENT_USER  or CURRENT_USER() . You cannot set the definer to any other account. 

Creating a stored object with a nonexistent DEFINER  account creates an orphan object, which may have negative consequences; see Orphan Stored Objects. 

## The SQL SECURITY Characteristic 

For stored routines (procedures and functions) and views, the object definition can include an SQL SECURITY  characteristic with a value of DEFINER  or INVOKER  to specify whether the object executes in definer or invoker context. If the definition omits the SQL SECURITY  characteristic, the default is definer context. 

Triggers and events have no SQL SECURITY  characteristic and always execute in definer context. The server invokes these objects automatically as necessary, so there is no invoking user. 

Definer and invoker security contexts differ as follows: 

•A stored object that executes in definer security context executes with the privileges of the account named by its DEFINER  attribute. These privileges may be entirely different from those of the invoking user. The invoker must have appropriate privileges to reference the object (for example, EXECUTE  to call a stored procedure or SELECT  to select from a view), but during object execution, the invoker’s privileges are ignored and only the DEFINER  account privileges matter. If the DEFINER  account has few privileges, the object is correspondingly limited in the operations it can perform. If the DEFINER  account is highly privileged (such as an administrative account), the object can perform powerful operations no matter who invokes it. 

•A stored routine or view that executes in invoker security context can perform only operations for which the invoker has privileges. The DEFINER  attribute has no effect on object execution. 

## Examples 

Consider the following stored procedure, which is declared with SQL SECURITY DEFINER  to execute in definer security context: 

CREATE DEFINER = ’admin’@’localhost’ PROCEDURE p1() SQL SECURITY DEFINER BEGIN UPDATE t1 SET counter = counter + 1; END; 

Any user who has the EXECUTE  privilege for p1  can invoke it with a CALL  statement. However, when p1  executes, it does so in definer security context and thus executes with the privileges of ’admin’@’localhost’ , the account named as its DEFINER  attribute. This account must have the 

