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).

1 files changed, 142 insertions, 2 deletions

diff --git a/mysql-test/t/view_grant.test b/mysql-test/t/view_grant.test
index ba603bde7f8..21c6f376f8a 100644
--- a/mysql-test/t/view_grant.test
+++ b/mysql-test/t/view_grant.test
@@ -1503,8 +1503,6 @@ SHOW CREATE VIEW v1;
 DROP TABLE t1;
 DROP VIEW v1;
 
-# Wait till we reached the initial number of concurrent sessions
---source include/wait_until_count_sessions.inc
 
 --echo #
 --echo # Bug #46019: ERROR 1356 When selecting from within another 
@@ -1546,3 +1544,145 @@ CREATE DEFINER=`unknown`@`unknown` SQL SECURITY DEFINER VIEW v1 AS SELECT 1;
 --error ER_NO_SUCH_USER
 LOCK TABLES v1 READ;
 DROP VIEW v1;
+
+
+--echo #
+--echo # Bug #58499 "DEFINER-security view selecting from INVOKER-security view
+--echo #             access check wrong".
+--echo #
+--echo # Check that we correctly handle privileges for various combinations
+--echo # of INVOKER and DEFINER-security views using each other.
+--disable_warnings
+DROP DATABASE IF EXISTS mysqltest1;
+--enable_warnings
+CREATE DATABASE mysqltest1;
+USE mysqltest1;
+CREATE TABLE t1 (i INT);
+CREATE TABLE t2 (j INT);
+INSERT INTO t1 VALUES (1);
+INSERT INTO t2 VALUES (2);
+--echo #
+--echo # 1) DEFINER-security view uses INVOKER-security view (covers
+--echo #    scenario originally described in the bug report).
+CREATE SQL SECURITY INVOKER VIEW v1_uses_t1 AS SELECT * FROM t1;
+CREATE SQL SECURITY INVOKER VIEW v1_uses_t2 AS SELECT * FROM t2;
+CREATE USER 'mysqluser1'@'%';
+GRANT CREATE VIEW ON mysqltest1.* TO 'mysqluser1'@'%';
+GRANT SELECT ON t1 TO 'mysqluser1'@'%';
+--echo # To be able create 'v2_uses_t2' we also need select on t2. 
+GRANT SELECT ON t2 TO 'mysqluser1'@'%';
+GRANT SELECT ON v1_uses_t1 TO 'mysqluser1'@'%';
+GRANT SELECT ON v1_uses_t2 TO 'mysqluser1'@'%';
+--echo #
+--echo # Connection 'mysqluser1'.
+--connect (mysqluser1, localhost, mysqluser1,,mysqltest1)
+CREATE SQL SECURITY DEFINER VIEW v2_uses_t1 AS SELECT * FROM v1_uses_t1;
+CREATE SQL SECURITY DEFINER VIEW v2_uses_t2 AS SELECT * FROM v1_uses_t2;
+--echo #
+--echo # Connection 'default'.
+--connection default
+CREATE USER 'mysqluser2'@'%';
+GRANT SELECT ON v2_uses_t1 TO 'mysqluser2'@'%';
+GRANT SELECT ON v2_uses_t2 TO 'mysqluser2'@'%';
+GRANT SELECT ON t2 TO 'mysqluser2'@'%';
+GRANT CREATE VIEW ON mysqltest1.* TO 'mysqluser2'@'%';
+--echo # Make 'mysqluser1' unable to access t2.
+REVOKE SELECT ON t2 FROM 'mysqluser1'@'%';
+--echo #
+--echo # Connection 'mysqluser2'.
+--connect (mysqluser2, localhost, mysqluser2,,mysqltest1)
+--echo # The below statement should succeed thanks to suid nature of v2_uses_t1.
+SELECT * FROM v2_uses_t1;
+--echo # The below statement should fail due to suid nature of v2_uses_t2.
+--error ER_VIEW_INVALID
+SELECT * FROM v2_uses_t2;
+--echo #
+--echo # 2) INVOKER-security view uses INVOKER-security view.
+--echo #
+--echo # Connection 'default'.
+--connection default
+DROP VIEW v2_uses_t1, v2_uses_t2;
+CREATE SQL SECURITY INVOKER VIEW v2_uses_t1 AS SELECT * FROM v1_uses_t1;
+CREATE SQL SECURITY INVOKER VIEW v2_uses_t2 AS SELECT * FROM v1_uses_t2;
+GRANT SELECT ON v2_uses_t1 TO 'mysqluser1'@'%';
+GRANT SELECT ON v2_uses_t2 TO 'mysqluser1'@'%';
+GRANT SELECT ON v1_uses_t1 TO 'mysqluser2'@'%';
+GRANT SELECT ON v1_uses_t2 TO 'mysqluser2'@'%';
+--echo #
+--echo # Connection 'mysqluser1'.
+--connection mysqluser1
+--echo # For both versions of 'v2' 'mysqluser1' privileges should be used.
+SELECT * FROM v2_uses_t1;
+--error ER_VIEW_INVALID
+SELECT * FROM v2_uses_t2;
+--echo #
+--echo # Connection 'mysqluser2'.
+--connection mysqluser2
+--echo # And now for both versions of 'v2' 'mysqluser2' privileges should
+--echo # be used.
+--error ER_VIEW_INVALID
+SELECT * FROM v2_uses_t1;
+SELECT * FROM v2_uses_t2;
+--echo #
+--echo # 3) INVOKER-security view uses DEFINER-security view.
+--echo #
+--echo # Connection 'default'.
+--connection default
+DROP VIEW v1_uses_t1, v1_uses_t2;
+--echo # To be able create 'v1_uses_t2' we also need select on t2. 
+GRANT SELECT ON t2 TO 'mysqluser1'@'%';
+--echo #
+--echo # Connection 'mysqluser1'.
+--connection mysqluser1
+CREATE SQL SECURITY DEFINER VIEW v1_uses_t1 AS SELECT * FROM t1;
+CREATE SQL SECURITY DEFINER VIEW v1_uses_t2 AS SELECT * FROM t2;
+--echo #
+--echo # Connection 'default'.
+--connection default
+--echo # Make 'mysqluser1' unable to access t2.
+REVOKE SELECT ON t2 FROM 'mysqluser1'@'%';
+--echo #
+--echo # Connection 'mysqluser2'.
+--connection mysqluser2
+--echo # Due to suid nature of v1_uses_t1 and v1_uses_t2 the first
+--echo # select should succeed and the second select should fail.
+SELECT * FROM v2_uses_t1;
+--error ER_VIEW_INVALID
+SELECT * FROM v2_uses_t2;
+--echo #
+--echo # 4) DEFINER-security view uses DEFINER-security view.
+--echo #
+--echo # Connection 'default'.
+--connection default
+DROP VIEW v2_uses_t1, v2_uses_t2;
+--echo # To be able create 'v2_uses_t2' we also need select on t2. 
+GRANT SELECT ON t2 TO 'mysqluser1'@'%';
+--echo #
+--echo # Connection 'mysqluser2'.
+--connection mysqluser2
+CREATE SQL SECURITY DEFINER VIEW v2_uses_t1 AS SELECT * FROM v1_uses_t1;
+CREATE SQL SECURITY DEFINER VIEW v2_uses_t2 AS SELECT * FROM v1_uses_t2;
+--echo #
+--echo # Connection 'default'.
+--connection default
+--echo # Make 'mysqluser1' unable to access t2.
+REVOKE SELECT ON t2 FROM 'mysqluser1'@'%';
+--echo #
+--echo # Connection 'mysqluser2'.
+--connection mysqluser2
+--echo # Again privileges of creator of innermost views should apply.
+SELECT * FROM v2_uses_t1;
+--error ER_VIEW_INVALID
+SELECT * FROM v2_uses_t2;
+
+--disconnect mysqluser1
+--disconnect mysqluser2
+--connection default
+USE test;
+DROP DATABASE mysqltest1;
+DROP USER 'mysqluser1'@'%';
+DROP USER 'mysqluser2'@'%';
+
+
+# Wait till we reached the initial number of concurrent sessions
+--source include/wait_until_count_sessions.inc