Bug#21975 Grant and revoke statements are non-transactional
Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
Bug#17244 GRANT gives strange error message when used in a stored function
GRANT/REVOKE statements are non-transactional (no explicit transaction
boundaries) in nature and hence are forbidden inside stored functions and
triggers, but they weren't being effectively forbidden. Furthermore, the
absence of implict commits makes changes made by GRANT/REVOKE statements to
not be rolled back.
The implemented fix is to issue a implicit commit with every GRANT/REVOKE
statement, effectively prohibiting these statements in stored functions
and triggers. The implicit commit also fixes the replication bug, and looks
like being in concert with the behavior of DDL and administrative statements.
Since this is a incompatible change, the following sentence should be
added to the Manual in the very end of the 3rd paragraph, subclause
13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
Patch contributed by Vladimir Shebordaev
mysql-test/r/sp-error.result:
Test case result for Bug#17244
mysql-test/t/sp-error.test:
Test case for Bug#17244
sql/sp_head.cc:
Set that a procedure with GRANT/REVOKE command has a (implicit or explicit)
commit.
sql/sql_parse.cc:
End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively
prohibit these statements in stored functions and triggers. An implicit commit
also fixes a bug in replication, when GRANT or REVOKE would disappear from the
binary log in case of a subsequent ROLLBACK, since they were considered
transactional statements.
mysql-test/suite/rpl/r/rpl_binlog_grant.result:
Add test case result for Bug#21975
mysql-test/suite/rpl/t/rpl_binlog_grant.test:
Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
|
|
|
drop database if exists d1;
|
|
|
|
create database d1;
|
|
|
|
use d1;
|
|
|
|
create table t (s1 int) engine=innodb;
|
|
|
|
set @@autocommit=0;
|
|
|
|
start transaction;
|
|
|
|
insert into t values (1);
|
|
|
|
grant select on t to x@y;
|
|
|
|
rollback;
|
|
|
|
show grants for x@y;
|
|
|
|
Grants for x@y
|
|
|
|
GRANT USAGE ON *.* TO 'x'@'y'
|
|
|
|
GRANT SELECT ON `d1`.`t` TO 'x'@'y'
|
|
|
|
show binlog events;
|
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
|
|
|
master-bin.000001 4 Format_desc 1 106 Server ver: VERSION, Binlog ver: 4
|
|
|
|
master-bin.000001 106 Query 1 193 drop database if exists d1
|
|
|
|
master-bin.000001 193 Query 1 272 create database d1
|
|
|
|
master-bin.000001 272 Query 1 370 use `d1`; create table t (s1 int) engine=innodb
|
|
|
|
master-bin.000001 370 Query 1 436 use `d1`; BEGIN
|
|
|
|
master-bin.000001 436 Query 1 521 use `d1`; insert into t values (1)
|
2007-09-06 12:06:22 -06:00
|
|
|
master-bin.000001 521 Xid 1 548 COMMIT /* XID */
|
Bug#21975 Grant and revoke statements are non-transactional
Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
Bug#17244 GRANT gives strange error message when used in a stored function
GRANT/REVOKE statements are non-transactional (no explicit transaction
boundaries) in nature and hence are forbidden inside stored functions and
triggers, but they weren't being effectively forbidden. Furthermore, the
absence of implict commits makes changes made by GRANT/REVOKE statements to
not be rolled back.
The implemented fix is to issue a implicit commit with every GRANT/REVOKE
statement, effectively prohibiting these statements in stored functions
and triggers. The implicit commit also fixes the replication bug, and looks
like being in concert with the behavior of DDL and administrative statements.
Since this is a incompatible change, the following sentence should be
added to the Manual in the very end of the 3rd paragraph, subclause
13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
Patch contributed by Vladimir Shebordaev
mysql-test/r/sp-error.result:
Test case result for Bug#17244
mysql-test/t/sp-error.test:
Test case for Bug#17244
sql/sp_head.cc:
Set that a procedure with GRANT/REVOKE command has a (implicit or explicit)
commit.
sql/sql_parse.cc:
End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively
prohibit these statements in stored functions and triggers. An implicit commit
also fixes a bug in replication, when GRANT or REVOKE would disappear from the
binary log in case of a subsequent ROLLBACK, since they were considered
transactional statements.
mysql-test/suite/rpl/r/rpl_binlog_grant.result:
Add test case result for Bug#21975
mysql-test/suite/rpl/t/rpl_binlog_grant.test:
Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
|
|
|
master-bin.000001 548 Query 1 633 use `d1`; grant select on t to x@y
|
|
|
|
start transaction;
|
|
|
|
insert into t values (2);
|
|
|
|
revoke select on t from x@y;
|
|
|
|
commit;
|
|
|
|
select * from t;
|
|
|
|
s1
|
|
|
|
1
|
|
|
|
2
|
|
|
|
show grants for x@y;
|
|
|
|
Grants for x@y
|
|
|
|
GRANT USAGE ON *.* TO 'x'@'y'
|
|
|
|
show binlog events;
|
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
|
|
|
master-bin.000001 4 Format_desc 1 106 Server ver: VERSION, Binlog ver: 4
|
|
|
|
master-bin.000001 106 Query 1 193 drop database if exists d1
|
|
|
|
master-bin.000001 193 Query 1 272 create database d1
|
|
|
|
master-bin.000001 272 Query 1 370 use `d1`; create table t (s1 int) engine=innodb
|
|
|
|
master-bin.000001 370 Query 1 436 use `d1`; BEGIN
|
|
|
|
master-bin.000001 436 Query 1 521 use `d1`; insert into t values (1)
|
2007-09-06 12:06:22 -06:00
|
|
|
master-bin.000001 521 Xid 1 548 COMMIT /* XID */
|
Bug#21975 Grant and revoke statements are non-transactional
Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
Bug#17244 GRANT gives strange error message when used in a stored function
GRANT/REVOKE statements are non-transactional (no explicit transaction
boundaries) in nature and hence are forbidden inside stored functions and
triggers, but they weren't being effectively forbidden. Furthermore, the
absence of implict commits makes changes made by GRANT/REVOKE statements to
not be rolled back.
The implemented fix is to issue a implicit commit with every GRANT/REVOKE
statement, effectively prohibiting these statements in stored functions
and triggers. The implicit commit also fixes the replication bug, and looks
like being in concert with the behavior of DDL and administrative statements.
Since this is a incompatible change, the following sentence should be
added to the Manual in the very end of the 3rd paragraph, subclause
13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
Patch contributed by Vladimir Shebordaev
mysql-test/r/sp-error.result:
Test case result for Bug#17244
mysql-test/t/sp-error.test:
Test case for Bug#17244
sql/sp_head.cc:
Set that a procedure with GRANT/REVOKE command has a (implicit or explicit)
commit.
sql/sql_parse.cc:
End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively
prohibit these statements in stored functions and triggers. An implicit commit
also fixes a bug in replication, when GRANT or REVOKE would disappear from the
binary log in case of a subsequent ROLLBACK, since they were considered
transactional statements.
mysql-test/suite/rpl/r/rpl_binlog_grant.result:
Add test case result for Bug#21975
mysql-test/suite/rpl/t/rpl_binlog_grant.test:
Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
|
|
|
master-bin.000001 548 Query 1 633 use `d1`; grant select on t to x@y
|
|
|
|
master-bin.000001 633 Query 1 699 use `d1`; BEGIN
|
|
|
|
master-bin.000001 699 Query 1 784 use `d1`; insert into t values (2)
|
2007-09-06 12:06:22 -06:00
|
|
|
master-bin.000001 784 Xid 1 811 COMMIT /* XID */
|
Bug#21975 Grant and revoke statements are non-transactional
Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
Bug#17244 GRANT gives strange error message when used in a stored function
GRANT/REVOKE statements are non-transactional (no explicit transaction
boundaries) in nature and hence are forbidden inside stored functions and
triggers, but they weren't being effectively forbidden. Furthermore, the
absence of implict commits makes changes made by GRANT/REVOKE statements to
not be rolled back.
The implemented fix is to issue a implicit commit with every GRANT/REVOKE
statement, effectively prohibiting these statements in stored functions
and triggers. The implicit commit also fixes the replication bug, and looks
like being in concert with the behavior of DDL and administrative statements.
Since this is a incompatible change, the following sentence should be
added to the Manual in the very end of the 3rd paragraph, subclause
13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
Patch contributed by Vladimir Shebordaev
mysql-test/r/sp-error.result:
Test case result for Bug#17244
mysql-test/t/sp-error.test:
Test case for Bug#17244
sql/sp_head.cc:
Set that a procedure with GRANT/REVOKE command has a (implicit or explicit)
commit.
sql/sql_parse.cc:
End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively
prohibit these statements in stored functions and triggers. An implicit commit
also fixes a bug in replication, when GRANT or REVOKE would disappear from the
binary log in case of a subsequent ROLLBACK, since they were considered
transactional statements.
mysql-test/suite/rpl/r/rpl_binlog_grant.result:
Add test case result for Bug#21975
mysql-test/suite/rpl/t/rpl_binlog_grant.test:
Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
|
|
|
master-bin.000001 811 Query 1 899 use `d1`; revoke select on t from x@y
|
|
|
|
drop user x@y;
|
|
|
|
drop database d1;
|