diff options
author | Martin Hansson <martin.hansson@sun.com> | 2009-09-28 13:25:47 +0200 |
---|---|---|
committer | Martin Hansson <martin.hansson@sun.com> | 2009-09-28 13:25:47 +0200 |
commit | e86f08d054e4de694071e0eef92ca4ca2b27cf2b (patch) | |
tree | 5e183973a70bf08f6abae39dc182fcecd2bedeb2 /sql/table.cc | |
parent | 96665fd9ccda9d9c129c5e421b10d00ccf78e5de (diff) | |
download | mariadb-git-e86f08d054e4de694071e0eef92ca4ca2b27cf2b.tar.gz |
Bug#35996: SELECT + SHOW VIEW should be enough to display
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.
mysql-test/r/information_schema_db.result:
Bug#35996: Changed warnings.
mysql-test/r/view_grant.result:
Bug#35996: Changed warnings, test result.
mysql-test/t/information_schema_db.test:
Bug#35996: Changed test case to reflect new behavior.
mysql-test/t/view_grant.test:
Bug#35996: Test case.
sql/sql_acl.cc:
Bug#35996: Code no longer necessary, we may as well exempt
SHOW CREATE VIEW from this check.
sql/sql_show.cc:
Bug#35996: The fix: An Internal_error_handler that hides
most errors raised by access checking as they are not
relevant to SHOW CREATE VIEW.
sql/table.cc:
Bug#35996: Restricting this hack to act only when there is
no Internal_error_handler.
Diffstat (limited to 'sql/table.cc')
-rw-r--r-- | sql/table.cc | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/sql/table.cc b/sql/table.cc index 4f647618979..04f2a3fbcf8 100644 --- a/sql/table.cc +++ b/sql/table.cc @@ -3338,7 +3338,12 @@ bool TABLE_LIST::prep_check_option(THD *thd, uint8 check_opt_type) /** - Hide errors which show view underlying table information + Hide errors which show view underlying table information. + There are currently two mechanisms at work that handle errors for views, + this one and a more general mechanism based on an Internal_error_handler, + see Show_create_error_handler. The latter handles errors encountered during + execution of SHOW CREATE VIEW, while the machanism using this method is + handles SELECT from views. The two methods should not clash. @param[in,out] thd thread handler @@ -3347,6 +3352,8 @@ bool TABLE_LIST::prep_check_option(THD *thd, uint8 check_opt_type) void TABLE_LIST::hide_view_error(THD *thd) { + if (thd->get_internal_handler()) + return; /* Hide "Unknown column" or "Unknown function" error */ DBUG_ASSERT(thd->is_error()); |