Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8628

Replication magic for CURRENT_USER in binlog does not work when binlog is replayed

    XMLWordPrintable

Details

    Description

      MySQL documentation says:

      CURRENT_USER() or CURRENT_USER is also expanded prior to being written to the binary log when used in DROP USER, RENAME USER, GRANT, REVOKE, or ALTER EVENT.

      It does not work like that.

      Test case

      --source include/master-slave.inc
      --source include/have_binlog_format_mixed.inc
       
      --enable_connect_log
       
      create user u1;
      grant all on *.* to u1 with grant option;
       
      --connect(con1,localhost,u1,,)
       
      grant select on db.* to current_user;
      revoke select on db.* from current_user;
      set password for current_user = password('test');
      rename user current_user to u2;
      rename user u2 to current_user;
      select current_user;
      drop user current_user;
       
      show binlog events;
       
      --disconnect con1
       
      --connection master
       
      select user, host from mysql.user;
       
      --sync_slave_with_master
       
      select user, host from mysql.user;

      The relevant part of the generated binlog:

      | wheezy-64-bin.000001 |  911 | Gtid              |         1 |         949 | GTID 0-1-5                                                                        |
      | wheezy-64-bin.000001 |  949 | Query             |         1 |        1054 | use `test`; grant select on db.* to current_user                                  |
      | wheezy-64-bin.000001 | 1054 | Gtid              |         1 |        1092 | GTID 0-1-6                                                                        |
      | wheezy-64-bin.000001 | 1092 | Query             |         1 |        1200 | use `test`; revoke select on db.* from current_user                               |
      | wheezy-64-bin.000001 | 1200 | Gtid              |         1 |        1238 | GTID 0-1-7                                                                        |
      | wheezy-64-bin.000001 | 1238 | Query             |         1 |        1376 | use `test`; SET PASSWORD FOR 'u1'@'%'='*94BDCEBE19083CE2A1F959FD02F964C7AF4CFC29' |
      | wheezy-64-bin.000001 | 1376 | Gtid              |         1 |        1414 | GTID 0-1-8                                                                        |
      | wheezy-64-bin.000001 | 1414 | Query             |         1 |        1513 | use `test`; rename user current_user to u2                                        |
      | wheezy-64-bin.000001 | 1513 | Gtid              |         1 |        1551 | GTID 0-1-9                                                                        |
      | wheezy-64-bin.000001 | 1551 | Query             |         1 |        1650 | use `test`; rename user u2 to current_user                                        |
      | wheezy-64-bin.000001 | 1650 | Gtid              |         1 |        1688 | GTID 0-1-10                                                                       |
      | wheezy-64-bin.000001 | 1688 | Query             |         1 |        1779 | use `test`; drop user current_user                                                |

      The only statement where CURRENT_USER is really expanded is SET PASSWORD.

      For replication it still works fine, replication magic allows to use the correct user which CURRENT_USER references to; but when the binary log is replayed by mysqlbinlog => mysql, it fails (produces wrong data).

      Also reproducible on MySQL 5.1 - 5.7.

      Attachments

        Activity

          People

            Unassigned Unassigned
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.