The DEFINER of a stored routine/view/trigger is stored, so that the definer's privileges can be used during execution if necessary. When this happens, the value of CURRENT_USER is changed to show the definer and not the invoker. But this change is not consistent over all statements; this task is to ensure that context changes to CURRENT_USER are handled consistently.
Some statements allow a DEFINER to be executed: - SQL SECURITY DEFINER characteristic for stored procedures and functions - SQL SECURITY DEFINER characteristic for views - CREATE TRIGGER has a DEFINER clause This causes the object to execute within a context that uses the definer's privileges rather than the invoker's privileges. For such objects, the meaning of the CURRENT_USER() function changes when executing in a context that uses the DEFINER privilege: It returns the definer account, not the invoker account. For example, SELECT CURRENT_USER() returns a value that changes in definer execution context. However, we have an inconsistency relating to CURRENT_USER(). For example, if you execute SHOW GRANTS FOR CURRENT_USER(), the output does *not* change in definer execution context. (For example, the output does not report the definer's privileges when the statement is executed in a SQL SECURITY DEFINER stored routine.) I have filed a bug report about this particular issue: BUG#15298 (SHOW GRANTS FOR CURRENT_USR: Incorrect output in DEFINER context) However, CURRENT_USER is one of the allowable expansions of the "user" production in sql_yacc.yy, and that production seems to be allowable in the grammar for a number of statements. SET PASSWORD FOR user RENAME USER user TO user DROP USER user ... This means that the CURRENT_USER issue in DEFINER context should be dealt with not just for SHOW GRANTS, but also for several other statements.