When expanding a * in a USING/NATURAL join the check for table access
for both tables in the join was done using the grant information of the
first one.
Fixed by getting the grant information for the current table while
iterating through the columns of the join.
In case of database level grant the database name may be a pattern,
in case of table|column level grant the database name can not be a pattern.
We use 'dont_check_global_grants' as a flag to determine
if it's database level grant command
(see SQLCOM_GRANT case, mysql_execute_command() function) and
set db_is_pattern according to 'dont_check_global_grants' value.
Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
by other connections"
Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
As well as:
Bug #25578 "CREATE TABLE LIKE does not require any privileges
on source table".
The first and the second bugs resulted in various errors and wrong
binary log order when one tried to execute concurrently CREATE TABLE LIKE
statement and DDL statements on source table or DML/DDL statements on its
target table.
The problem was caused by incomplete protection/table-locking against
concurrent statements implemented in mysql_create_like_table() routine.
We solve it by simply implementing such protection in proper way (see
comment for sql_table.cc for details).
The third bug allowed user who didn't have any privileges on table create
its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
This patch solves this problem by adding privilege check, which was missing.
Finally it also removes some duplicated code from mysql_create_like_table().
Note that, altough tests covering concurrency-related aspects of CREATE TABLE
LIKE behaviour will only be introduced in 5.1, they were run manually for
this patch as well.
multi-threaded environment".
To avoid deadlocks between several simultaneously run account management
commands (particularly between FLUSH PRIVILEGES/SET PASSWORD and GRANT
commands) we should always take table and internal locks during their
execution in the same order. In other words we should first open and lock
privilege tables and only then obtain acl_cache::lock/LOCK_grant locks.
Added new logic to ACL system:
1) If GRANT OPTION (not mysql db):
Ok to update existing user, but not password.
Not allowed to make a new user.
2) If UPDATE_ACL to mysql DB:
Ok to update current user, but not make a new one.
3) If INSERT_ACL to mysql DB:
Ok to add a new user, but not modify existing.
4) If GRANT OPTION to mysql DB:
All modifications OK.
First one is related to Bug#7905. One should not be allowed to
create new user with password without UPDATE privilege to
MySQL database. Furthermore, executing the same GRANT statement
twice would actually crash the server and corrupt privilege database.
Other bug was that one could update a column, using the existing
value as basis to calculate the new value (e.g. UPDATE t1 SET a=a+1)
without SELECT privilege to the field (a in the above example)
Fixed tests grant.pl and grant2, which were wrong.
are not specified in an insert. Most of these changes are actually to
clean up the test suite to either specify defaults to avoid warnings,
or add the warnings to the results. Related to bug #5986.
he has SELECT and INSERT privileges for table with primary key"
Now we set lex->duplicates= DUP_UPDATE right in parser if INSERT has
ON DUPLICATE KEY UPDATE clause, this simplifies insert_precheck()
function (this also fixes a bug) and some other code.
'SHOW GRANTS' syntax is added
'SHOW GRANTS FOR CURRENT_USER' syntax is added
'SHOW GRANTS FOR CURRENT_USER()' syntax is added
CURRENT_USER without parens in expressions(SELECT CURRENT_USER;)
