Backport of:
------------------------------------------------------------
revno: 2630.4.1
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-3726-w
timestamp: Fri 2008-05-23 17:54:03 +0400
message:
WL#3726 "DDL locking for all metadata objects".
After review fixes in progress.
------------------------------------------------------------
This is the first patch in series. It transforms the metadata
locking subsystem to use a dedicated module (mdl.h,cc). No
significant changes in the locking protocol.
The import passes the test suite with the exception of
deprecated/removed 6.0 features, and MERGE tables. The latter
are subject to a fix by WL#4144.
Unfortunately, the original changeset comments got lost in a merge,
thus this import has its own (largely insufficient) comments.
This patch fixes Bug#25144 "replication / binlog with view breaks".
Warning: this patch introduces an incompatible change:
Under LOCK TABLES, it's no longer possible to FLUSH a table that
was not locked for WRITE.
Under LOCK TABLES, it's no longer possible to DROP a table or
VIEW that was not locked for WRITE.
******
Backport of:
------------------------------------------------------------
revno: 2630.4.2
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-3726-w
timestamp: Sat 2008-05-24 14:03:45 +0400
message:
WL#3726 "DDL locking for all metadata objects".
After review fixes in progress.
******
Backport of:
------------------------------------------------------------
revno: 2630.4.3
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-3726-w
timestamp: Sat 2008-05-24 14:08:51 +0400
message:
WL#3726 "DDL locking for all metadata objects"
Fixed failing Windows builds by adding mdl.cc to the lists
of files needed to build server/libmysqld on Windows.
******
Backport of:
------------------------------------------------------------
revno: 2630.4.4
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-3726-w
timestamp: Sat 2008-05-24 21:57:58 +0400
message:
WL#3726 "DDL locking for all metadata objects".
Fix for assert failures in kill.test which occured when one
tried to kill ALTER TABLE statement on merge table while it
was waiting in wait_while_table_is_used() for other connections
to close this table.
These assert failures stemmed from the fact that cleanup code
in this case assumed that temporary table representing new
version of table was open with adding to THD::temporary_tables
list while code which were opening this temporary table wasn't
always fulfilling this.
This patch changes code that opens new version of table to
always do this linking in. It also streamlines cleanup process
for cases when error occurs while we have new version of table
open.
******
WL#3726 "DDL locking for all metadata objects"
Add libmysqld/mdl.cc to .bzrignore.
******
Backport of:
------------------------------------------------------------
revno: 2630.4.6
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-3726-w
timestamp: Sun 2008-05-25 00:33:22 +0400
message:
WL#3726 "DDL locking for all metadata objects".
Addition to the fix of assert failures in kill.test caused by
changes for this worklog.
Make sure we close the new table only once.
The flag EXTRA_ACL is used in conjugation with our access checks, yet it is
not clear what impact this flag has.
This is a code clean up which replaces use of EXTRA_ACL with an explicit
function parameter.
The patch also fixes privilege checks for:
- SHOW CREATE TABLE: The new privilege requirement is any privilege on
the table-level.
- CHECKSUM TABLE: Requires SELECT on the table level.
- SHOW CREATE VIEW: Requires SHOW_VIEW and SELECT on the table level
(just as the manual claims)
- SHOW INDEX: Requires any privilege on any column combination.
view that has Group By
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.
view definition
During SHOW CREATE VIEW there is no reason to 'anonymize'
errors that name objects that a user does not have access
to. Moreover it was inconsistently implemented. For example
base tables being referenced from a view appear to be ok,
but not views. The manual on the other hand is clear: If a
user has the privileges SELECT and SHOW VIEW, the view
definition is available to that user, period. The fix
changes the behavior to support the manual.
view that has Group By
Table access rights checking function check_grant() assumed
that no view is opened when it's called.
This is not true with nested views where the inner view
needs materialization. In this case the view is already
materialized when check_grant() is called for it.
This caused check_grant() to not look for table level
grants on the materialized view table.
Fixed by checking if a view is already materialized and if
it is check table level grants using the original table name
(not the ones of the materialized temp table).
+ Fix for Bug#43114 wait_until_count_sessions too restrictive, random PB failures
+ Removal of a lot of other weaknesses found
+ modifications according to review
statement/stored procedure
View privileges are properly checked after the fix for bug no
36086, so the method TABLE_LIST::get_db_name() must be used
instead of field TABLE_LIST::db, as this only works for tables.
Bug appears when accessing views in prepared statements.
This patch also fixes bugs 36963 and 35600.
- In many places a view was confused with an anonymous derived
table, i.e. access checking was skipped. Fixed by introducing a
predicate to tell the difference between named and anonymous
derived tables.
- When inserting fields for "SELECT * ", there was no
distinction between base tables and views, where one should be
made. View privileges are checked elsewhere.
a table name.
The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).
The fix is to ensure that an error is thrown even if the table
is in the cache.
(This is a backport of the original patch for 5.1)
Non-definer of a view was allowed to alter that view. Due to this the alterer
can elevate his access rights to access rights of the view definer and thus
modify data which he wasn't allowed to modify. A view defined with
SQL SECURITY INVOKER can't be used directly for access rights elevation.
But a user can first alter the view SQL code and then alter the view to
SQL SECURITY DEFINER and thus elevate his access rights. Due to this
altering a view with SQL SECURITY INVOKER is also prohibited.
Now the mysql_create_view function allows ALTER VIEW only to the view
definer or a super user.
another user.
When the DEFINER clause isn't specified in the ALTER statement then it's loaded
from the view definition. If the definer differs from the current user then
the error is thrown because only a super-user can set other users as a definers.
Now if the DEFINER clause is omitted in the ALTER VIEW statement then the
definer from the original view is used without check.
on a database.
The problem was that we required not less privileges on the base tables
than we have on the view.
The fix is to be more flexible and allow to create such a view (necessary
privileges will be checked at the runtime).
The problem was that if a prepared statement accessed a view, the
access to the tables listed in the query after that view was done in
the security context of the view.
The bug was in the assigning of the security context to the tables
belonging to a view: we traversed the list of all query tables
instead. It didn't show up in the normal (non-prepared) statements
because of the different order of the steps of checking privileges
and descending into a view for normal and prepared statements.
The solution is to traverse the list and stop once the last table
belonging to the view was processed.
If a view was created with the DEFINER security and later the definer user
was dropped then a SELECT from the view throws the error message saying that
there is no definer user is registered. This is ok for a root but too much
for a mere user.
Now the st_table_list::prepare_view_securety_context() function reveals
the absence of the definer only to a superuser and throws the 'access denied'
error to others.
(Mostly in DBUG_PRINT() and unused arguments)
Fixed bug in query cache when used with traceing (--with-debug)
Fixed memory leak in mysqldump
Removed warnings from mysqltest scripts (replaced -- with #)
