Details
-
Task
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
If you want to set the rocksdb_create_checkpoint system variable, then you need the SUPER privilege. This is not exactly unexpected since it is a GLOBAL system variable.
From the MySQL documentation:
Setting a global system variable runtime value requires the SUPER privilege.
https://dev.mysql.com/doc/refman/5.5/en/system-variable-privileges.html
The problem is that Mariabackup uses this system variable to backup MyRocks data. This limitation means that MyRocks data can only be backed up by Mariabackup if the user account has the SUPER privilege. See MDEV-20564.
This has been documented now:
https://mariadb.com/kb/en/library/mariabackup-overview/#authentication-and-privileges
I think some users would dislike the idea of making the backup user require SUPER privileges. Would it be possible and desirable to change MyRocks, so that a lower privilege than SUPER is required in order to set the rocksdb_create_checkpoint system variable? Should the system variable be made into a SESSION system variable?
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
No, this is impossible. All global variables require SUPER, this is unconditionally checked in set_var::check()
No, this is impossible. All global variables require SUPER, this is unconditionally checked in set_var::check()
Some ideas:
- Would it be reasonable to make rocksdb_create_checkpoint settable at a SESSION level, or would that have other problems?
- Instead of making Mariabackup set the rocksdb_create_checkpoint system variable, would it be worthwhile to make a mysql.rocksdb_create_checkpoint UDF that requires lesser privileges to run?
- Do we want to just leave it as-is, and not change anything?
Yes, see innodb_tmpdir variable and its innodb_tmpdir_validate
function.
I see that function checks for the FILE privilege:
https://github.com/MariaDB/server/blob/mariadb-10.4.8/storage/innobase/handler/ha_innodb.cc#L759
Ignore the "yes" comment, it was sent as an email and somehow arrived into jira much later than expected, after I've added the correct "no" one (even though "yes" was sent first).
Yes, making rocksdb_create_checkpoint a session variable looks like the easiest fix here.
I'm not aware of any way a plugin could specify that "this global variable can be set by a user other than SUPER" ( serg, any idea? ).
I'm wondering if other storage engines had a similar issue and how it was solved?