EXECUTE  privilege for p1  as well as the UPDATE  privilege for the table t1  referenced within the object body. Otherwise, the procedure fails. 

Now consider this stored procedure, which is identical to p1  except that its SQL SECURITY  characteristic is INVOKER : 

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

Unlike p1 , p2  executes in invoker security context and thus with the privileges of the invoking user regardless of the DEFINER  attribute value. p2  fails if the invoker lacks the EXECUTE  privilege for p2  or the UPDATE  privilege for the table t1 . 

## Orphan Stored Objects 

An orphan stored object is one for which its DEFINER  attribute names a nonexistent account: 

•An orphan stored object can be created by specifying a nonexistent DEFINER  account at object-creation time. 

•An existing stored object can become orphaned through execution of a DROP USER  statement that drops the object DEFINER  account, or a RENAME USER  statement that renames the object DEFINER  account. 

An orphan stored object may be problematic in these ways: 

•Because the DEFINER  account does not exist, the object may not work as expected if it executes in definer security context: 

•For a stored routine, an error occurs at routine execution time if the SQL SECURITY  value is DEFINER but the definer account does not exist. 

•For a trigger, it is not a good idea for trigger activation to occur until the account actually does exist. Otherwise, the behavior with respect to privilege checking is undefined. 

•For an event, an error occurs at event execution time if the account does not exist. 

•For a view, an error occurs when the view is referenced if the SQL SECURITY  value is DEFINER  but the definer account does not exist. 

•The object may present a security risk if the nonexistent DEFINER  account is subsequently re-created for a purpose unrelated to the object. In this case, the account “adopts”  the object and, with the appropriate privileges, is able to execute it even if that is not intended. 

As of MySQL 8.0.22, the server imposes additional account-management security checks designed to prevent operations that (perhaps inadvertently) cause stored objects to become orphaned or that cause adoption of stored objects that are currently orphaned: 

• DROP USER  fails with an error if any account to be dropped is named as the DEFINER  attribute for any stored object. (That is, the statement fails if dropping an account would cause a stored object to become orphaned.) 

• RENAME USER  fails with an error if any account to be renamed is named as the DEFINER  attribute for any stored object. (That is, the statement fails if renaming an account would cause a stored object to become orphaned.) 

