summaryrefslogtreecommitdiff
path: root/mysql-test/t/view_grant.test
diff options
context:
space:
mode:
authorunknown <kroki/tomash@moonlight.home>2007-01-18 12:48:17 +0300
committerunknown <kroki/tomash@moonlight.home>2007-01-18 12:48:17 +0300
commit0541dcad3bd09dc616298d7cc18c5a8c9d1e7458 (patch)
treed8be64e6bf82da7be443651ebd6320ba80f9b1cf /mysql-test/t/view_grant.test
parentd501b2dd3966d4f236b46a3b3bb7b89929e25716 (diff)
downloadmariadb-git-0541dcad3bd09dc616298d7cc18c5a8c9d1e7458.tar.gz
Bug#24404: strange bug with view+permission+prepared statement.
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. mysql-test/r/view_grant.result: Add result for bug#24404: strange bug with view+permission+prepared statement. mysql-test/t/view_grant.test: Add test case for bug#24404: strange bug with view+permission+prepared statement. sql/sql_view.cc: Remove dead line. When setting security context, we should traverse the list of tables belonging to a given view, not all query tables. We achieve that by stopping at the first table past view_tables_tail.
Diffstat (limited to 'mysql-test/t/view_grant.test')
-rw-r--r--mysql-test/t/view_grant.test72
1 files changed, 71 insertions, 1 deletions
diff --git a/mysql-test/t/view_grant.test b/mysql-test/t/view_grant.test
index 4a3a29e3afe..ea6dbeb0a4b 100644
--- a/mysql-test/t/view_grant.test
+++ b/mysql-test/t/view_grant.test
@@ -927,4 +927,74 @@ DROP VIEW v2;
DROP VIEW v1;
DROP USER mysqltest_u1@localhost;
-# End of 5.0 tests.
+
+#
+# BUG#24404: strange bug with view+permission+prepared statement
+#
+--disable_warnings
+DROP DATABASE IF EXISTS mysqltest_db1;
+DROP DATABASE IF EXISTS mysqltest_db2;
+--enable_warnings
+--error 0,ER_CANNOT_USER
+DROP USER mysqltest_u1;
+--error 0,ER_CANNOT_USER
+DROP USER mysqltest_u2;
+
+CREATE USER mysqltest_u1@localhost;
+CREATE USER mysqltest_u2@localhost;
+
+CREATE DATABASE mysqltest_db1;
+CREATE DATABASE mysqltest_db2;
+
+GRANT ALL ON mysqltest_db1.* TO mysqltest_u1@localhost WITH GRANT OPTION;
+GRANT ALL ON mysqltest_db2.* TO mysqltest_u2@localhost;
+
+connect (conn1, localhost, mysqltest_u1, , mysqltest_db1);
+
+CREATE TABLE t1 (i INT);
+INSERT INTO t1 VALUES (1);
+
+# Use view with subquery for better coverage.
+CREATE VIEW v1 AS SELECT i FROM t1 WHERE 1 IN (SELECT * FROM t1);
+
+CREATE TABLE t2 (s CHAR(7));
+INSERT INTO t2 VALUES ('public');
+
+GRANT SELECT ON v1 TO mysqltest_u2@localhost;
+GRANT SELECT ON t2 TO mysqltest_u2@localhost;
+
+connect (conn2, localhost, mysqltest_u2, , mysqltest_db2);
+
+SELECT * FROM mysqltest_db1.v1, mysqltest_db1.t2;
+PREPARE stmt1 FROM "SELECT * FROM mysqltest_db1.t2";
+EXECUTE stmt1;
+PREPARE stmt2 FROM "SELECT * FROM mysqltest_db1.v1, mysqltest_db1.t2";
+EXECUTE stmt2;
+
+connection conn1;
+# Make table 't2' private.
+REVOKE SELECT ON t2 FROM mysqltest_u2@localhost;
+UPDATE t2 SET s = 'private' WHERE s = 'public';
+
+connection conn2;
+--error ER_TABLEACCESS_DENIED_ERROR
+SELECT * FROM mysqltest_db1.v1, mysqltest_db1.t2;
+--error ER_TABLEACCESS_DENIED_ERROR
+EXECUTE stmt1;
+# Original bug was here: the statement didn't fail.
+--error ER_TABLEACCESS_DENIED_ERROR
+EXECUTE stmt2;
+
+# Cleanup.
+disconnect conn2;
+disconnect conn1;
+connection default;
+REVOKE ALL ON mysqltest_db1.* FROM mysqltest_u1@localhost;
+REVOKE ALL ON mysqltest_db2.* FROM mysqltest_u2@localhost;
+DROP DATABASE mysqltest_db1;
+DROP DATABASE mysqltest_db2;
+DROP USER mysqltest_u1@localhost;
+DROP USER mysqltest_u2@localhost;
+
+
+--echo End of 5.0 tests.