[MDEV-22030] Don't grant REPLICATION MASTER ADMIN automatically on upgrade from an older JSON user table Created: 2020-03-24  Updated: 2022-01-25  Resolved: 2020-03-24

Status: Closed
Project: MariaDB Server
Component/s: Authentication and Privilege System
Fix Version/s: 10.5.2

Type: Task Priority: Major
Reporter: Alexander Barkov Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MDEV-22040 versioning.truncate_privilege : GRANT... Closed
Relates
relates to MDEV-21743 Split up SUPER privilege to smaller p... Closed
relates to MDEV-22026 Document 10.5 privilege changes Closed
relates to MDEV-23610 Slave user can't run "SHOW SLAVE STAT... Closed
relates to MDEV-27611 CLONE - Slave user can't run "SHOW SL... Closed

 Description   

The SHOW SLAVE HOSTS statement:

  • required REPLICATION SLAVE privilege prior to 10.5.2 (which was not good from the security point of view: a user with REPLICATION SLAVE should not be able to see other slaves connected to the same master - it should only be able to connect to the master using the replication IO to pull binlog events)
  • requires REPLICATION MASTER ADMIN privilege since 10.5.2

The original patch for MDEV-21743 automatically granted REPLICATION MASTER ADMIN on upgrade to any user that had REPLICATION SLAVE before the upgrade. The idea was to automatically allow SHOW SLAVE HOSTS after upgrade to all users who were able to do so before the upgrade.

However, later we also bound the following statements to REPLICATION MASTER ADMIN (under terms of MDEV-21967, MDEV-21972, MDEV-21973):

  • SET GLOBAL rpl_semi_sync_master_enabled
  • SET GLOBAL rpl_semi_sync_master_timeout
  • SET GLOBAL rpl_semi_sync_master_wait_no_slave
  • SET GLOBAL rpl_semi_sync_master_trace_level
  • SET GLOBAL rpl_semi_sync_master_wait_point
  • SET GLOBAL master_verify_checksum
  • SET GLOBAL gtid_binlog_state
  • SET GLOBAL server_id
  • SET GLOBAL gtid_domain_id

It's not a good idea to give access to set these global variables on the master to any user who is only supposed to communicate with the master from slave (using the replication IO protocol).

Let's revert this change: REPLICATION MASTER ADMIN should not be granted automatically when reading user data from a pre-10.5.2 JSON table. The DBA after the upgrade will have to do GRANT REPLICATION MASTER ADMIN to all users who need SHOW SLAVE HOSTS. This is an incompatible change and should be mentioned in the documentation explicitly.

Note, we revert this automatic grant for upgrade from an older (pre-10.5.2) JSON user table only!

There is no a way to GRANT REPLICATION MASTER ADMIN with the old-style (pre-10.4) user table. So let's keep this behavior and keep automatic grant of REPLICATION MASTER ADMIN for all users that had REPLICATION SLAVE in the pre-10.4 user table. This will allow to do SHOW SLAVE HOSTS with the old pre-10.4 user table. After upgrade from the pre-10.4 user table to JSON table, the DBA will have to revoke REPLICATION MASTER ADMIN from any users who do not really need it.
Generated at Thu Feb 08 09:11:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.