mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 21:42:35 +01:00
eaae675279
discover its existence". The problem was that user without any privileges on routine was able to find out whether it existed or not. DROP FUNCTION and DROP PROCEDURE statements were checking if routine being dropped existed and reported ER_SP_DOES_NOT_EXIST error/warning before checking if user had enough privileges to drop it. This patch solves this problem by changing code not to check if routine exists before checking if user has enough privileges to drop it. Moreover we no longer perform this check using a separate call instead we rely on sp_drop_routine() returning SP_KEY_NOT_FOUND if routine doesn't exist. This change also simplifies one of upcoming patches refactoring global read lock implementation. mysql-test/r/grant.result: Updated test case after fixing bug#57061 "User without privilege on routine can discover its existence". Removed DROP PROCEDURE/FUNCTION statements which have started to fail after this fix (correctly). There is no need in dropping routines in freshly created database anyway. mysql-test/r/sp-security.result: Added new test case for bug#57061 "User without privilege on routine can discover its existence". Updated existing tests according to new behaviour. mysql-test/suite/funcs_1/r/innodb_storedproc_06.result: Updated test case after fixing bug#57061 "User without privilege on routine can discover its existence". Now we drop routines under user which has enough privileges to do so. mysql-test/suite/funcs_1/r/memory_storedproc_06.result: Updated test case after fixing bug#57061 "User without privilege on routine can discover its existence". Now we drop routines under user which has enough privileges to do so. mysql-test/suite/funcs_1/r/myisam_storedproc_06.result: Updated test case after fixing bug#57061 "User without privilege on routine can discover its existence". Now we drop routines under user which has enough privileges to do so. mysql-test/suite/funcs_1/storedproc/storedproc_06.inc: Updated test case after fixing bug#57061 "User without privilege on routine can discover its existence". Now we drop routines under user which has enough privileges to do so. mysql-test/t/grant.test: Updated test case after fixing bug#57061 "User without privilege on routine can discover its existence". Removed DROP PROCEDURE/FUNCTION statements which have started to fail after this fix (correctly). There is no need in dropping routines in freshly created database anyway. mysql-test/t/sp-security.test: Added new test case for bug#57061 "User without privilege on routine can discover its existence". Updated existing tests according to new behaviour. sql/sp.cc: Removed sp_routine_exists_in_table() which is no longer used. sql/sp.h: Removed sp_routine_exists_in_table() which is no longer used. sql/sql_parse.cc: When dropping routine we no longer check if routine exists before checking if user has enough privileges to do so. Moreover we no longer perform this check using a separate call instead we rely on sp_drop_routine() returning SP_KEY_NOT_FOUND if routine doesn't exist. |
||
---|---|---|
.. | ||
bitdata | ||
cursors | ||
datadict | ||
include | ||
lib | ||
r | ||
storedproc | ||
t | ||
triggers | ||
views | ||
README.txt |
2008-02-29 Matthias Leich ========================= 1. The testsuite "funcs_1" is mostly intended for additional (compared to the common regression tests stored in mysql-test/t) checks of features (VIEWS, INFORMATION_SCHEMA, STORED PROCEDURES,...) introduced with MySQL 5.0. 2. There were some extensions of this suite when new information_schema views were introduced. But in most cases the tests for these views were stored within the regression testsuite (mysql-test/t). INFORMATION_SCHEMA views introduced with MySQL 5.1 ================================================== ENGINES (partially tested here) EVENTS (partially tested here) FILES GLOBAL_STATUS GLOBAL_VARIABLES PARTITIONS PLUGINS PROCESSLIST (full tested here) PROFILING REFERENTIAL_CONSTRAINTS SESSION_STATUS SESSION_VARIABLES 3. Some hints for maintainers of this suite: - SHOW TABLES ... LIKE '<pattern>' does a case sensitive comparison between the tablename and the pattern. The names of the tables within the informationschema are in uppercase. So please use something like SHOW TABLES FOR information_schema LIKE 'TABLES' when you intend to get the same non empty result set on OS with and without case sensitive filesystems and default configuration. - The name of the data dictionary is 'information_schema' (lowercase). - Server on OS with filesystem with case sensitive filenames (= The files 'abc' and 'Abc' can coexist.) + default configuration Example of behaviour: DROP DATABASE information_schema; ERROR 42000: Access denied for user ... to database 'information_schema' DROP DATABASE INFORMATION_SCHEMA; ERROR 42000: Access denied for user ... to database 'INFORMATION_SCHEMA' - Try to unify results by --replace_result $engine_type <engine_to_be_tested> if we could expect that the results for storage engine variants of a test differ only in the engine names. This makes future maintenance easier. - Avoid the use of include/show_msg*.inc. They produce "SQL" noise which annoys during server debugging and can be easy replaced by "--echo ...".