mariadb/mysql-test/r/ps_grant.result

88 lines
3.8 KiB
Text
Raw Normal View History

test_sequence
------ grant/revoke/drop affects a parallel session test ------
show grants for second_user@localhost ;
ERROR 42000: There is no such grant defined for user 'second_user' on host 'localhost'
create database mysqltest;
use mysqltest;
use test;
grant usage on mysqltest.* to second_user@localhost
identified by 'looser' ;
grant select on mysqltest.t9 to second_user@localhost
identified by 'looser' ;
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
select current_user();
current_user()
second_user@localhost
show grants for current_user();
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
prepare s_t9 from 'select c1 as my_col
from t9 where c1= 1' ;
execute s_t9 ;
my_col
1
select a as my_col from t1;
ERROR 42000: SELECT command denied to user 'second_user'@'localhost' for table 't1'
grant select on mysqltest.t1 to second_user@localhost
identified by 'looser' ;
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
Bug#41049 does syntax "grant" case insensitive? Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME). mysql-test/include/have_case_insensitive_fs.inc: test case mysql-test/r/case_insensitive_fs.require: test case mysql-test/r/grant_lowercase_fs.result: test result mysql-test/r/lowercase_fs_off.result: test result mysql-test/r/ps_grant.result: test result mysql-test/r/system_mysql_db.result: changed Routine_name field collation to case insensitive mysql-test/t/grant_lowercase_fs.test: test case mysql-test/t/lowercase_fs_off.test: test case scripts/mysql_system_tables.sql: changed Routine_name field collation to case insensitive scripts/mysql_system_tables_fix.sql: changed Routine_name field collation to case insensitive sql/sql_acl.cc: Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME).
2009-10-27 09:09:19 +01:00
GRANT SELECT ON `mysqltest`.`t1` TO 'second_user'@'localhost'
drop table mysqltest.t9 ;
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
Bug#41049 does syntax "grant" case insensitive? Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME). mysql-test/include/have_case_insensitive_fs.inc: test case mysql-test/r/case_insensitive_fs.require: test case mysql-test/r/grant_lowercase_fs.result: test result mysql-test/r/lowercase_fs_off.result: test result mysql-test/r/ps_grant.result: test result mysql-test/r/system_mysql_db.result: changed Routine_name field collation to case insensitive mysql-test/t/grant_lowercase_fs.test: test case mysql-test/t/lowercase_fs_off.test: test case scripts/mysql_system_tables.sql: changed Routine_name field collation to case insensitive scripts/mysql_system_tables_fix.sql: changed Routine_name field collation to case insensitive sql/sql_acl.cc: Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME).
2009-10-27 09:09:19 +01:00
GRANT SELECT ON `mysqltest`.`t1` TO 'second_user'@'localhost'
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
Bug#41049 does syntax "grant" case insensitive? Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME). mysql-test/include/have_case_insensitive_fs.inc: test case mysql-test/r/case_insensitive_fs.require: test case mysql-test/r/grant_lowercase_fs.result: test result mysql-test/r/lowercase_fs_off.result: test result mysql-test/r/ps_grant.result: test result mysql-test/r/system_mysql_db.result: changed Routine_name field collation to case insensitive mysql-test/t/grant_lowercase_fs.test: test case mysql-test/t/lowercase_fs_off.test: test case scripts/mysql_system_tables.sql: changed Routine_name field collation to case insensitive scripts/mysql_system_tables_fix.sql: changed Routine_name field collation to case insensitive sql/sql_acl.cc: Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME).
2009-10-27 09:09:19 +01:00
GRANT SELECT ON `mysqltest`.`t1` TO 'second_user'@'localhost'
prepare s_t1 from 'select a as my_col from t1' ;
execute s_t1 ;
my_col
1
2
3
4
execute s_t9 ;
ERROR 42S02: Table 'mysqltest.t9' doesn't exist
deallocate prepare s_t9;
revoke all privileges on mysqltest.t1 from second_user@localhost
identified by 'looser' ;
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
GRANT SELECT ON `mysqltest`.`t9` TO 'second_user'@'localhost'
execute s_t1 ;
ERROR 42000: SELECT command denied to user 'second_user'@'localhost' for table 't1'
revoke all privileges, grant option from second_user@localhost ;
show grants for second_user@localhost ;
Grants for second_user@localhost
GRANT USAGE ON *.* TO 'second_user'@'localhost' IDENTIFIED BY PASSWORD '*13843FE600B19A81E32AF50D4A6FED25875FF1F3'
drop user second_user@localhost ;
commit ;
show grants for second_user@localhost ;
ERROR 42000: There is no such grant defined for user 'second_user' on host 'localhost'
drop database mysqltest;
prepare stmt3 from ' grant all on test.t1 to drop_user@localhost
identified by ''looser'' ';
grant all on test.t1 to drop_user@localhost
identified by 'looser' ;
prepare stmt3 from ' revoke all privileges on test.t1 from
drop_user@localhost ';
revoke all privileges on test.t1 from drop_user@localhost ;
prepare stmt3 from ' drop user drop_user@localhost ';
drop user drop_user@localhost;