Orphan Stored Objects 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. •Because the  DEFINER  account does not exist, the object may not work as expected if it executes in definer security context: An orphan stored object may be problematic in these ways: •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.) 4752