Bug#44658 Create procedure makes server crash when user does not have ALL privilege

MySQL crashes if a user without proper privileges attempts to create a procedure.

The crash happens because more than one error state is pushed onto the Diagnostic
area. In this particular case the user is denied to implicitly create a new user
account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE.

The new account is needed if the original user account contained a host mask.
A user account with a host mask is a distinct user account in this context.
An alternative would be to first get the most permissive user account which
include the current user connection and then assign privileges to that
account. This behavior change is considered out of scope for this bug patch.

The implicit assignment of privileges when a user creates a stored routine is a
considered to be a feature for user convenience and as such it is not
a critical operation. Any failure to complete this operation is thus considered
non-fatal (an error becomes a warning).

The patch back ports a stack implementation of the internal error handler interface.
This enables the use of multiple error handlers so that it is possible to intercept
and cancel errors thrown by lower layers. This is needed as a error handler already
is used in the call stack emitting the errors which needs to be converted.


mysql-test/r/grant.result:
  * Added test case for bug44658
mysql-test/t/grant.test:
  * Added test case for bug44658
sql/sp.cc:
  * Removed non functional parameter no_error and my_error calls as all errors
    from this function will be converted to a warning anyway.
  * Change function return type from int to bool.
sql/sp.h:
  * Removed non functional parameter no_error and my_error calls as all errors
    from this function will be converted to a warning anyway.
  * Changed function return value from int to bool
sql/sql_acl.cc:
  * Removed the non functional no_error parameter from the function prototype.
    The function is called from two places and in one of the places we now 
    ignore errors through error handlers.
  * Introduced the parameter write_to_binlog
  * Introduced an error handler to cancel any error state from mysql_routine_grant.
  * Moved my_ok() signal from mysql_routine_grant to make it easier to avoid
    setting the wrong state in the Diagnostic area.
  * Changed the broken error state in sp_grant_privileges() to a warning
    so that if "CREATE PROCEDURE" fails because "Password hash isn't a hexidecimal
    number" it is still clear what happened.
sql/sql_acl.h:
  * Removed the non functional no_error parameter from the function prototype.
    The function is called from two places and in one of the places we now 
    ignore errors through error handlers.
  * Introduced the parameter write_to_binlog
  * Changed return type for sp_grant_privileges() from int to bool
sql/sql_class.cc:
  * Back ported implementation of internal error handler from 6.0 branch
sql/sql_class.h:
  * Back ported implementation of internal error handler from 6.0 branch
sql/sql_parse.cc:
  * Moved my_ok() signal from mysql_routine_grant() to make it easier to avoid
    setting the wrong state in the Diagnostic area.

1 files changed, 55 insertions, 0 deletions

diff --git a/mysql-test/r/grant.result b/mysql-test/r/grant.result
index de80a83d538..a677d71b266 100644
--- a/mysql-test/r/grant.result
+++ b/mysql-test/r/grant.result
@@ -1358,3 +1358,58 @@ DROP USER 'userbug33464'@'localhost';
 USE test;
 DROP DATABASE dbbug33464;
 SET @@global.log_bin_trust_function_creators= @old_log_bin_trust_function_creators;
+CREATE USER user1;
+CREATE USER user2;
+GRANT CREATE ON db1.* TO 'user1'@'localhost';
+GRANT CREATE ROUTINE ON db1.* TO 'user1'@'localhost';
+GRANT CREATE ON db1.* TO 'user2'@'%';
+GRANT CREATE ROUTINE ON db1.* TO 'user2'@'%';
+FLUSH PRIVILEGES;
+SHOW GRANTS FOR 'user1'@'localhost';
+Grants for user1@localhost
+GRANT USAGE ON *.* TO 'user1'@'localhost'
+GRANT CREATE, CREATE ROUTINE ON `db1`.* TO 'user1'@'localhost'
+** Connect as user1 and create a procedure.
+** The creation will imply implicitly assigned
+** EXECUTE and ALTER ROUTINE privileges to
+** the current user user1@localhost. 
+SELECT @@GLOBAL.sql_mode;
+@@GLOBAL.sql_mode
+
+SELECT @@SESSION.sql_mode;
+@@SESSION.sql_mode
+
+CREATE DATABASE db1;
+CREATE PROCEDURE db1.proc1(p1 INT)
+BEGIN
+SET @x = 0;
+REPEAT SET @x = @x + 1; UNTIL @x > p1 END REPEAT;
+END ;||
+** Connect as user2 and create a procedure.
+** Implicitly assignment of privileges will
+** fail because the user2@localhost is an
+** unknown user.
+CREATE PROCEDURE db1.proc2(p1 INT)
+BEGIN
+SET @x = 0;
+REPEAT SET @x = @x + 1; UNTIL @x > p1 END REPEAT;
+END ;||
+Warnings:
+Warning	1404	Failed to grant EXECUTE and ALTER ROUTINE privileges
+SHOW GRANTS FOR 'user1'@'localhost';
+Grants for user1@localhost
+GRANT USAGE ON *.* TO 'user1'@'localhost'
+GRANT CREATE, CREATE ROUTINE ON `db1`.* TO 'user1'@'localhost'
+GRANT EXECUTE, ALTER ROUTINE ON PROCEDURE `db1`.`proc1` TO 'user1'@'localhost'
+SHOW GRANTS FOR 'user2';
+Grants for user2@%
+GRANT USAGE ON *.* TO 'user2'@'%'
+GRANT CREATE, CREATE ROUTINE ON `db1`.* TO 'user2'@'%'
+DROP PROCEDURE db1.proc1;
+DROP PROCEDURE db1.proc2;
+REVOKE ALL ON db1.* FROM 'user1'@'localhost';
+REVOKE ALL ON db1.* FROM 'user2'@'%';
+DROP USER 'user1';
+DROP USER 'user1'@'localhost';
+DROP USER 'user2';
+DROP DATABASE db1;