Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1.34, 10.3.8, 5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL)
Description
Test user has all privileges but SUPER, and read-only is set.
This gets detected correctly when trying to create a new database, or when trying to change the character set of an existing table:
MariaDB [test]> create database test2;
|
ERROR 1290 (HY000): The MariaDB server is running with the --read-only option so it cannot execute this statement
|
|
|
MariaDB [test]> alter table t1 character set latin1;
|
ERROR 1290 (HY000): The MariaDB server is running with the --read-only option so it cannot execute this statement
|
Changing the default character set of an existing database is possible though, it does not raise any error, and the changes effect even though the MariaDB instance is in read-only mode:
MariaDB [test]> alter database test character set latin1;
|
Query OK, 1 row affected (0.001 sec)
|
|
|
MariaDB [test]> show create database test;
|
+----------+-----------------------------------------------------------------+
|
| Database | Create Database |
|
+----------+-----------------------------------------------------------------+
|
| test | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */ |
|
+----------+-----------------------------------------------------------------+
|
1 row in set (0.000 sec)
|
|
|
MariaDB [test]> alter database test character set utf8;
|
Query OK, 1 row affected (0.001 sec)
|
|
|
MariaDB [test]> show create database test;
|
+----------+---------------------------------------------------------------+
|
| Database | Create Database |
|
+----------+---------------------------------------------------------------+
|
| test | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8 */ |
|
+----------+---------------------------------------------------------------+
|
1 row in set (0.000 sec)
|
Attachments
Activity
hholzgra, sorry, you're right. I misread your test cases.
I wonder if ALTER DATABASE ... UPGRADE should be fixed as well?
Fix itself is fairly simple:
diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc
|
index f357f8b..d1f75eb 100644
|
--- a/sql/sql_parse.cc
|
+++ b/sql/sql_parse.cc
|
@@ -566,7 +566,7 @@ void init_update_queries(void)
|
sql_command_flags[SQLCOM_CREATE_PACKAGE_BODY]= CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS;
|
sql_command_flags[SQLCOM_DROP_PACKAGE_BODY]= CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS;
|
sql_command_flags[SQLCOM_ALTER_DB_UPGRADE]= CF_AUTO_COMMIT_TRANS;
|
- sql_command_flags[SQLCOM_ALTER_DB]= CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS;
|
+ sql_command_flags[SQLCOM_ALTER_DB]= CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS | CF_DB_CHANGE;
|
sql_command_flags[SQLCOM_RENAME_TABLE]= CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS;
|
sql_command_flags[SQLCOM_DROP_INDEX]= CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS | CF_REPORT_PROGRESS;
|
sql_command_flags[SQLCOM_CREATE_VIEW]= CF_CHANGES_DATA | CF_REEXECUTION_FRAGILE |
|
ok to push.
Although, I'd push it into an earlier version. 10.1 or even 5.5.
"I wonder if ALTER DATABASE ... UPGRADE should be fixed as well?"
Maybe .. but on the other hand it does not perform any changes visible to the SQL layer, so it shouldn't really matter.
I can't see a slave getting out of sync with its master due to this, so it is probably acceptable even with read_only=true
While "no updates" may seem to imply DML only, all DDL operations are blocked, too.
The only exception seems to be ALTER DATABASE.
That's what the bug report is about: why this single DDL exception?
PS: also please note that I wrote "Test user has all privileges but SUPER", not "Test user has SUPER privilege".