summaryrefslogtreecommitdiff
path: root/mysql-test/r/grant3.result
diff options
context:
space:
mode:
authorSatya B <satya.bn@sun.com>2009-10-20 11:47:57 +0530
committerSatya B <satya.bn@sun.com>2009-10-20 11:47:57 +0530
commit882535423de244036c8d26b055aeaf292d3abaf7 (patch)
tree122c2042c60d1805493e1268a3edef8b9a19dcd8 /mysql-test/r/grant3.result
parent128e676c0d7ada2d7d79e3e8c80f7804915bf8c8 (diff)
downloadmariadb-git-882535423de244036c8d26b055aeaf292d3abaf7.tar.gz
Fix for Bug #41597 - After rename of user, there are additional grants when
grants are reapplied. After renaming a user and trying to re-apply grants results in additional grants. This is because we use username as part of the key for GRANT_TABLE structure. When the user is renamed, we only change the username stored and the hash key still contains the old user name and this results in the extra privileges Fixed by rebuilding the hash key and updating the column_priv_hash structure when the user is renamed mysql-test/r/grant3.result: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Testcase for BUG#41597 mysql-test/t/grant3.test: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Testcase for BUG#41597 sql/sql_acl.cc: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Fixed handle_grant_struct() to update the hash key when the user is renamed. Added to set_user_details() method to GRANT_NAME class
Diffstat (limited to 'mysql-test/r/grant3.result')
-rw-r--r--mysql-test/r/grant3.result38
1 files changed, 38 insertions, 0 deletions
diff --git a/mysql-test/r/grant3.result b/mysql-test/r/grant3.result
index f38848111ad..59c64ee84ae 100644
--- a/mysql-test/r/grant3.result
+++ b/mysql-test/r/grant3.result
@@ -154,4 +154,42 @@ SELECT * FROM mysqltest_1.t1;
a
DROP USER 'mysqltest1'@'%';
DROP DATABASE mysqltest_1;
+#
+# Bug#41597 - After rename of user, there are additional grants
+# when grants are reapplied.
+#
+CREATE DATABASE temp;
+CREATE TABLE temp.t1(a INT, b VARCHAR(10));
+INSERT INTO temp.t1 VALUES(1, 'name1');
+INSERT INTO temp.t1 VALUES(2, 'name2');
+INSERT INTO temp.t1 VALUES(3, 'name3');
+CREATE USER 'user1'@'%';
+RENAME USER 'user1'@'%' TO 'user2'@'%';
+# Show privileges after rename and BEFORE grant
+SHOW GRANTS FOR 'user2'@'%';
+Grants for user2@%
+GRANT USAGE ON *.* TO 'user2'@'%'
+GRANT SELECT (a), INSERT (b) ON `temp`.`t1` TO 'user2'@'%';
+# Show privileges after rename and grant
+SHOW GRANTS FOR 'user2'@'%';
+Grants for user2@%
+GRANT USAGE ON *.* TO 'user2'@'%'
+GRANT SELECT (a), INSERT (b) ON `temp`.`t1` TO 'user2'@'%'
+# Connect as the renamed user
+SHOW GRANTS;
+Grants for user2@%
+GRANT USAGE ON *.* TO 'user2'@'%'
+GRANT SELECT (a), INSERT (b) ON `temp`.`t1` TO 'user2'@'%'
+SELECT a FROM temp.t1;
+a
+1
+2
+3
+# Check for additional privileges by accessing a
+# non privileged column. We shouldn't be able to
+# access this column.
+SELECT b FROM temp.t1;
+ERROR 42000: SELECT command denied to user 'user2'@'localhost' for column 'b' in table 't1'
+DROP USER 'user2'@'%';
+DROP DATABASE temp;
End of 5.0 tests