database.
If a user has a right to update anything in the current database then the
access was granted and further checks of access rights for underlying tables
wasn't done correctly. The check is done before a view is opened and thus no
check of access rights for underlying tables can be carried out.
This allows a user to update through a view a table from another database for
which he hasn't enough rights.
Now the mysql_update() and the mysql_test_update() functions are forces
re-checking of access rights after a view is opened.
The problem was that THD::db_access variable was not restored after
database switch in stored-routine-execution code.
The fix is to restore THD::db_access in this case.
Unfortunately, this fix requires additional changes,
because in prepare_schema_table(), called on the parsing stage, we checked
privileges. That was wrong according to our design, but this flaw haven't
struck so far, because it was masked. All privilege checkings must be
done on the execution stage in order to be compatible with prepared statements
and stored routines. So, this patch also contains patch for
prepare_schema_table(), which moves the checkings to the execution phase.
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.
The fix is to check length of user/host name in parser and if string is too
long, throw an error.
"A SELECT privilege on a view is required for SHOW CREATE VIEW and it will stay
that way because of compatibility reasons." (see #20136)
a test case to illustrate how the ACLs work in this case (and ensure they will continue
to do so in the future)
The check for view security was lacking several points :
1. Check with the right set of permissions : for each table ref that
participates in a view there were the right credentials to use in it's
security_ctx member, but these weren't used for checking the credentials.
This makes hard enforcing the SQL SECURITY DEFINER|INVOKER property
consistently.
2. Because of the above the security checking for views was just ruled out
in explicit ways in several places.
3. The security was checked only for the columns of the tables that are
brought into the query from a view. So if there is no column reference
outside of the view definition it was not detecting the lack of access to
the tables in the view in SQL SECURITY INVOKER mode.
The fix below tries to fix the above 3 points.
- In function 'handle_grant_struct' when searching the memory structures for an
entry to modify, convert all entries here host.hostname is NULL to "" and compare that
with the host passed in argument "user_from".
- A user created with hostname "" is stored in "mysql.user" table as host="" but when loaded into
memory it'll be stored as host.hostname NULL. Specifiying "" as hostname means
that "any host" can connect. Thus is's correct to turn on allow_all_hosts
when such a user is found.
- Review and fix other places where host.hostname may be NULL.
ps_grant.result:
Fixing result order.
grant.result:
Adding test case,
fixing result order.
grant.test:
Adding test case.
sql_acl.cc:
Fixed that my_charset_latin1 was incorrectly used instead of system_charset_info.
This problem was previously fixed by Ingo in 5.0.
This patch is basically a backport of the same changes into 4.1.
fixing tests accordingly
item.cc:
Bug #10892 user variables not auto cast for comparisons
When mixing strings with different character sets,
and coercibility is the same, we allow conversion
if one character set is superset for other character set.
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.
