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

Session tracking does not report changes from COM_CHANGE_USER

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.5, 10.6, 10.11, 11.4, 11.8
    • 12.0.1
    • Protocol, Server
    • None

    Description

      When COM_CHANGE_USER is executed, it resets the context, including session variables and the current schema, but session tracking doesn't notice any of this.

      create user foo@localhost;
      set @track_schema= @@session_track_schema, @track_vars= @@session_track_system_variables;
      set global session_track_schema=ON, session_track_system_variables='*';
       
      --connect(con1,localhost,root,,)
      set lock_wait_timeout=22;
      select @@lock_wait_timeout, database();
      --echo # Running change_user
      --enable_session_track_info
      --change_user foo
      --disable_session_track_info
      select @@lock_wait_timeout, database();
       
      --disconnect con1
      --connection default
      drop user foo@localhost;
      set global session_track_schema= @track_schema, session_track_system_variables= @track_vars;
      

      main ab468e33aff110b44a31ce0350894906ff4bc757

      @@lock_wait_timeout	database()
      22	test
      # Running change_user
      select @@lock_wait_timeout, database();
      @@lock_wait_timeout	database()
      86400	NULL
       

      The same is true for SET SESSION AUTHORIZATION command introduced in MDEV-20299.

      Attachments

        Issue Links

          Activity

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.