We do not accept:
1. We did not have this problem (fixed earlier and better)
d982e717ab Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES
2. We do not have such options (an DBUG_ASSERT put just in case)
bbc2e37fe4 Bug#27759871: BACKRONYM ISSUE IS STILL IN MYSQL 5.7
3. Serg fixed it in other way in this release:
e48d775c6f Bug#27980823: HEAP OVERFLOW VULNERABILITIES IN MYSQL CLIENT LIBRARY
It should work ok on all Unixes, but on Windows ,only worked by accident
in the past, with client not being Unicode safe.
It stopped working with Visual Studio 2017 15.7 update now.
SHOW_ROUTINE_GRANTS
Description :- Server crashes in show_routine_grants().
Analysis :- When "grant_reload_procs_priv" encounters
an error, the grant structures (structures with column,
function and procedure privileges) are freed. Server
crashes when trying to access these structures later.
Fix :- Grant structures are retained even when
"grant_reload_procs_priv()" encounters an error while
reloading column, function and procedure privileges.
INSERT PRIVILEGES FOR MYSQL.USER TABLE
Description:- Incorrect granting of EXECUTE and ALTER
ROUTINE privileges when the 'automatic_sp_privileges'
variable is set.
Fix:- EXECUTE and ALTER ROUTINE privileges are correctly
granted to the creator of the procedure when the
'automatic_sp_privileges' is SET.
use update_hostname() to update the hostname.
test case comes from
commit 0abdeed1d6d
Author: gopal.shankar@oracle.com <>
Date: Thu Mar 29 00:20:54 2012 +0530
Bug#12766319 - 61865: RENAME USER DOES NOT WORK CORRECTLY -
REQUIRES FLUSH PRIVILEGES
FUNCTIONS/PRIVILEGES DIFFERENTLY'.
The problem was that attempt to grant EXECUTE or ALTER
ROUTINE privilege on stored procedure which didn't exist
succeed instead of returning an appropriate error like
it happens in similar situation for stored functions or
tables.
The code which handles granting of privileges on individual
routine calls sp_exist_routines() function to check if routine
exists and assumes that the 3rd parameter of the latter
specifies whether it should check for existence of stored
procedure or function. In practice, this parameter had
completely different meaning and, as result, this check was
not done properly for stored procedures.
This fix addresses this problem by bringing sp_exist_routines()
signature and code in line with expectation of its caller.
configuration wizard to fail
Made the fields mysql.user.plugin and mysql.user.authentication_string
nullable to conform with some older clients doing inserts instead of
using the commands.
configuration wizard to fail
Made the fields mysql.user.plugin and mysql.user.authentication_string
nullable to conform with some older clients doing inserts instead of
using the commands.
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.
mysql-test/r/grant.result:
Added test coverage for bug#36544 "DROP USER does not remove stored
function privileges".
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
Since after fixing bug#36544 "DROP USER does not remove stored function
privileges" in-memory structures are correctly updated by DROP USER,
DROP FUNCTION performed after DROP USER for its definer no longer
produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
Since after fixing bug#36544 "DROP USER does not remove stored function
privileges" in-memory structures are correctly updated by DROP USER,
DROP FUNCTION performed after DROP USER for its definer no longer
produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
Since after fixing bug#36544 "DROP USER does not remove stored function
privileges" in-memory structures are correctly updated by DROP USER,
DROP FUNCTION performed after DROP USER for its definer no longer
produces unwarranted warning/error messages.
mysql-test/t/grant.test:
Added test coverage for bug#36544 "DROP USER does not remove stored
function privileges".
sql/sql_acl.cc:
Changed handle_grant_data() to also update hash with function
privileges. This allows DROP/RENAME USER correctly keep this
in-memory structure up-to-date.
To do this extended handle_grant_struct() to support updating of this
hash. In addition fixed code in this function which is responsible for
handling of column and routine hashes during RENAME USER, ensured that
we correctly update these hashes after changing user name and that we
don't skip elements while iterating through the hash and doing updates.
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.
The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.
A similar problem existed for stored programs: the changes between
executions didn't have an effect.
Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.
The fix is to check them there as it happens in find_field_in_table_ref().
The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.
A similar problem existed for stored programs: the changes between
executions didn't have an effect.
Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.
The fix is to check them there as it happens in find_field_in_table_ref().
mysql-test/r/grant.result:
It was added result for test case for bug#36742.
mysql-test/t/grant.test:
It was added test case for bug#36742.
sql/sql_yacc.yy:
It was added convertation of host name part of user name to lowercase.
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.
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.
Fall back to use ALTER TABLE for engines that doesn't support REPAIR when doing repair for upgrade.
Nicer output from mysql_upgrade and mysql_check
Updated all arrays that used NAME_LEN to use SAFE_NAME_LEN to ensure that we don't break things accidently as names can now have a #mysql50# prefix.
client/mysql_upgrade.c:
If we are using verbose, also run mysqlcheck in verbose mode.
client/mysqlcheck.c:
Add more information if running in verbose mode
Print 'Needs upgrade' instead of complex error if table needs to be upgraded
Don't write connect information if verbose is not 2 or above
mysql-test/r/drop.result:
Updated test and results as we now support full table names
mysql-test/r/grant.result:
Now you get a correct error message if using #mysql with paths
mysql-test/r/show_check.result:
Update results as table names can temporarly be bigger than NAME_LEN (during upgrade)
mysql-test/r/upgrade.result:
Test upgrade for long table names.
mysql-test/suite/funcs_1/r/is_tables_is.result:
Updated old test result (had note been updated in a while)
mysql-test/t/drop.test:
Updated test and results as we now support full table names
mysql-test/t/grant.test:
Now you get a correct error message if using #mysql with paths
mysql-test/t/upgrade.test:
Test upgrade for long table names.
sql/ha_partition.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/item.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/log_event.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/mysql_priv.h:
Added SAFE_NAME_LEN
sql/rpl_filter.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sp.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sp_head.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_acl.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_base.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_connect.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_parse.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_prepare.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_select.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_show.cc:
NAME_LEN -> SAFE_NAME_LEN
Enlarge table names for SHOW TABLES to also include optional #mysql50#
sql/sql_table.cc:
Fall back to use ALTER TABLE for engines that doesn't support REPAIR when doing repair for upgrade.
sql/sql_trigger.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_udf.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_view.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/table.cc:
Fixed check_table_name() to not count #mysql50# as part of name
If #mysql50# is part of the name, don't allow path characters in name.
Conflicts:
Text conflict in mysql-test/r/grant.result
Text conflict in mysql-test/t/grant.test
Text conflict in mysys/mf_loadpath.c
Text conflict in sql/slave.cc
Text conflict in sql/sql_priv.h
Conflicts:
Text conflict in mysql-test/r/grant.result
Text conflict in mysql-test/t/grant.test
Text conflict in mysys/mf_loadpath.c
Text conflict in sql/slave.cc
Text conflict in sql/sql_priv.h
This is the 5.1 merge and extension of the fix.
The server was happily accepting paths in table name in all places a table
name is accepted (e.g. a SELECT). This allowed all users that have some
privilege over some database to read all tables in all databases in all
mysql server instances that the server file system has access to.
Fixed by :
1. making sure no path elements are allowed in quoted table name when
constructing the path (note that the path symbols are still valid in table names
when they're properly escaped by the server).
2. checking the #mysql50# prefixed names the same way they're checked for
path elements in mysql-5.0.
This is the 5.1 merge and extension of the fix.
The server was happily accepting paths in table name in all places a table
name is accepted (e.g. a SELECT). This allowed all users that have some
privilege over some database to read all tables in all databases in all
mysql server instances that the server file system has access to.
Fixed by :
1. making sure no path elements are allowed in quoted table name when
constructing the path (note that the path symbols are still valid in table names
when they're properly escaped by the server).
2. checking the #mysql50# prefixed names the same way they're checked for
path elements in mysql-5.0.
Makefile.am:
add new API files to the check_abi rule,
remove duplicates
client/CMakeLists.txt:
now a client can use dlopen too
client/Makefile.am:
be csh-friendly
include/my_global.h:
add dummy plugs for dlopen and co.
for the code that needs them to work in static builds
mysys/Makefile.am:
be csh-friendly
plugin/auth/dialog.c:
typo fixed
