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

SHOW GRANTS does not work for a replicated role (throws 'There is no such grant defined for user ...')

Details

    • 10.1.10

    Description

      Test case

      --source include/master-slave.inc
       
      --enable_connect_log
       
      create user u1;
      create role r1;
      --echo #
      --echo # On master SHOW GRANTS work both for the user and the role:
      show grants for u1;
      show grants for r1;
      --echo #
      --sync_slave_with_master
      --echo #
      --echo # The role has been replicated, 
      --echo # it's visible in mysql.user and I_S:
      --echo #
      select user, host, is_role from mysql.user;
      select * from information_schema.applicable_roles;
      --echo #
      --disable_abort_on_error
      --echo #
      --echo # For the new user, SHOW GRANTS works:
      show grants for u1;
      --echo #
      --echo # But for the new role, it does not:
      show grants for r1;
      --echo #
      --echo # FLUSH PRIVILEGES does not help:
      flush privileges;
      show grants for r1;
      --echo #
      --echo # The role can be set, but SHOW GRANTS for it still does not work:
      set role r1;
      show grants for r1;
      --echo #
      --echo # However, in the user's SHOW GRANTS it's visible
      show grants;

      Printed comments in the test case pretty much describe it all. I create a role on the master, wait till it's replicated to the slave, but SHOW GRANTS FOR <this role> does not work, even though otherwise it appears to be fine.

      Not reproducible on 10.0.

      Attachments

        Issue Links

          Activity

            cvicentiu Vicențiu Ciorbaru added a comment - - edited

            During show grants, we call get_current_user in order to figure out if we are supposed to print grants for a user or a role.

            get_current_user looked for ssl related information being set in thd->lex->ssl_*. Unfortunately, our parser did not initialise the lex->ssl_* related structure fields correctly during the SHOW GRANTS statement. By adding clear_privileges in the parsing grammar, which initialises the fields, we fix this problem. For a more sound fix however we should refactor any settings related to users (be it resource quota, or ssl authentication) to be attached to the LEX_USER structure. This should be part of a future patch, perhaps in 10.2.

            cvicentiu Vicențiu Ciorbaru added a comment - - edited During show grants, we call get_current_user in order to figure out if we are supposed to print grants for a user or a role. get_current_user looked for ssl related information being set in thd->lex->ssl_*. Unfortunately, our parser did not initialise the lex->ssl_* related structure fields correctly during the SHOW GRANTS statement. By adding clear_privileges in the parsing grammar, which initialises the fields, we fix this problem. For a more sound fix however we should refactor any settings related to users (be it resource quota, or ssl authentication) to be attached to the LEX_USER structure. This should be part of a future patch, perhaps in 10.2.

            Hi Sergei!

            Can you please review the patch submitted on the commits mailing list related to this bug.

            Thanks,
            Vicentiu

            cvicentiu Vicențiu Ciorbaru added a comment - Hi Sergei! Can you please review the patch submitted on the commits mailing list related to this bug. Thanks, Vicentiu
            cvicentiu Vicențiu Ciorbaru added a comment - Fixed with: afc2fb1bf8aaa8559f602bf7ff7859e039a378ee

            People

              cvicentiu Vicențiu Ciorbaru
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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