Fix for bug #58499 "DEFINER-security view selecting from
INVOKER-security view access check wrong". When privilege checks were done for tables used from an INVOKER-security view which in its turn was used from a DEFINER-security view connection's active security context was incorrectly used instead of security context with privileges of the second view's creator. This meant that users which had enough rights to access the DEFINER-security view and as result were supposed to be able successfully access it were unable to do so in cases when they didn't have privileges on underlying tables of the INVOKER-security view. This problem was caused by the fact that for INVOKER-security views TABLE_LIST::security_ctx member for underlying tables were set to 0 even in cases when particular view was used from another DEFINER-security view. This meant that when checks of privileges on these underlying tables was done in setup_tables_and_check_access() active connection security context was used instead of context corresponding to the creator of caller view. This fix addresses the problem by ensuring that underlying tables of an INVOKER-security view inherit security context from the view and thus correct security context is used for privilege checks on underlying tables in cases when such view is used from another view with DEFINER-security. mysql-test/r/view_grant.result: Added coverage for various combinations of DEFINER and INVOKER-security views, including test for bug #58499 "DEFINER-security view selecting from INVOKER-security view access check wrong". mysql-test/t/view_grant.test: Added coverage for various combinations of DEFINER and INVOKER-security views, including test for bug #58499 "DEFINER-security view selecting from INVOKER-security view access check wrong". sql/sql_view.cc: When opening a non-suid view ensure that its underlying tables will get the same security context as use for checking privileges on the view, i.e. security context of view invoker. This context can be different from the security context which is currently active for connection in cases when this non-suid view is used from a view with suid security. Inheriting security context in such situation allows correctly apply privileges of creator of suid view in checks for tables of non-suid view (since in this situation creator/definer of suid view serves as invoker for non-suid view).
Showing
Please register or sign in to comment