mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 13:32:33 +01:00
e960abc7cf
privileges". The first problem was that DROP USER didn't properly remove privileges on stored functions from in-memory structures. So the dropped user could have called stored functions on which he had privileges before being dropped while his connection was still around. Even worse if a new user with the same name was created he would inherit privileges on stored functions from the dropped user. Similar thing happened with old user name and function privileges during RENAME USER. This problem stemmed from the fact that the handle_grant_data() function which handled DROP/RENAME USER didn't take any measures to update in-memory hash with information about function privileges after updating them on disk. This patch solves this problem by adding code doing just that. The second problem was that RENAME USER didn't properly update in-memory structures describing table-level privileges and privileges on stored procedures. As result such privileges could have been lost after a rename (i.e. not associated with the new name of user) and inherited by a new user with the same name as the old name of the original user. This problem was caused by code handling RENAME USER in handle_grant_struct() which [sic!]: a) tried to update wrong (tables) hash when updating stored procedure privileges for new user name. b) passed wrong arguments to function performing the hash update and didn't take into account the way in which such update could have changed the order of the hash elements. This patch solves this problem by ensuring that a) the correct hash is updated, b) correct arguments are used for the hash_update() function and c) we take into account possible changes in the order of hash elements. |
||
|---|---|---|
| .. | ||
| 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 ...".