| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
use table_alias_charset for comparing table names, not files_charset_info
|
| |/
|
|
| |
stopped with no-zero size)
|
| |
|
|
|
|
| |
discover its existence by executing "select non_existing_func();" or by "call non_existing_proc()"
add or move privilege checks before existence checks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that RENAME TABLE caused an assert if the system variable
lower_case_table_names was 2 (default on Mac OS X) and the old table name
was given in upper case. This caused lowercase_table2.test to fail.
The assert checks that an exclusive metadata lock is held by the connection
trying to do RENAME TABLE - specificially during updates of table triggers.
The assert was triggered since the check is case sensitive and the lock
was held on the normalized (lower case) version of the table name.
This patch fixes the problem by making sure a normalized version of the
table name is used for the metadata lock check, while using a non-normalized
version of the table name for the rename of trigger files. The same is done
for ALTER TABLE ... RENAME.
Regression testing for the bug itself is already covered by
lowercase_table2.test. Additional coverage added to lowercase_fs_off.test.
|
| |\ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
mysql-test/r/limit.result:
Add missing drop of table t1
mysql-test/r/lowercase_fs_off.result:
Add missing drop of "sample" user
mysql-test/t/limit.test:
Add missing drop of table t1
mysql-test/t/lowercase_fs_off.test:
Add missing drop of "sample" user
|
|
|
Problem:
if a user was granted privileges on database "d1",
it also was able to act on "D1" (i.e. in upper case),
even on Unix with case sensitive file system.
Fix:
Initialize grant hash to use binary comparison
if lower_case_file_system is not set (on most unixes),
and case insensitive comparison otherwise (Windows, MacOSX).
sql/sql_acl.cc:
Initialize hash to use binary comparison with case sensitive FS.
mysql-test/include/have_case_sensitive_file_system.inc:
New BitKeeper file ``mysql-test/include/have_case_sensitive_file_system.inc''
Backporting from 5.1
mysql-test/r/case_sensitive_file_system.require:
New BitKeeper file ``mysql-test/r/case_sensitive_file_system.require''
Backporting from 5.1
mysql-test/r/lowercase_fs_off.result:
Adding test case
mysql-test/t/lowercase_fs_off.test:
Adding test case
|
