mariadb/mysql-test/r/lowercase_fs_off.result
Sergey Glukhov f0a7ff8419 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 12:09:19 +04:00

57 lines
1.8 KiB
Text

create database d1;
grant all on d1.* to 'sample'@'localhost' identified by 'password';
flush privileges;
select database();
database()
d1
create database d2;
ERROR 42000: Access denied for user 'sample'@'localhost' to database 'd2'
create database D1;
ERROR 42000: Access denied for user 'sample'@'localhost' to database 'D1'
drop user 'sample'@'localhost';
drop database if exists d1;
CREATE DATABASE d1;
USE d1;
CREATE TABLE T1(f1 INT);
CREATE TABLE t1(f1 INT);
GRANT SELECT ON T1 to user_1@localhost;
select * from t1;
ERROR 42000: SELECT command denied to user 'user_1'@'localhost' for table 't1'
select * from T1;
f1
GRANT SELECT ON t1 to user_1@localhost;
select * from information_schema.table_privileges;
GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
'user_1'@'localhost' NULL d1 T1 SELECT NO
'user_1'@'localhost' NULL d1 t1 SELECT NO
REVOKE ALL PRIVILEGES, GRANT OPTION FROM user_1@localhost;
DROP USER user_1@localhost;
DROP DATABASE d1;
USE test;
CREATE DATABASE db1;
USE db1;
CREATE PROCEDURE p1() BEGIN END;
CREATE FUNCTION f1(i INT) RETURNS INT RETURN i+1;
GRANT USAGE ON db1.* to user_1@localhost;
GRANT EXECUTE ON PROCEDURE db1.P1 to user_1@localhost;
GRANT EXECUTE ON FUNCTION db1.f1 to user_1@localhost;
GRANT UPDATE ON db1.* to USER_1@localhost;
call p1();
call P1();
select f1(1);
f1(1)
2
call p1();
ERROR 42000: execute command denied to user 'USER_1'@'localhost' for routine 'db1.p1'
call P1();
ERROR 42000: execute command denied to user 'USER_1'@'localhost' for routine 'db1.p1'
select f1(1);
ERROR 42000: execute command denied to user 'USER_1'@'localhost' for routine 'db1.f1'
REVOKE ALL PRIVILEGES, GRANT OPTION FROM user_1@localhost;
REVOKE ALL PRIVILEGES, GRANT OPTION FROM USER_1@localhost;
DROP FUNCTION f1;
DROP PROCEDURE p1;
DROP USER user_1@localhost;
DROP USER USER_1@localhost;
DROP DATABASE db1;
use test;