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

Server audit incorrectly logs user or database for COM_CHANGE_USER and following queries

Details

    Description

      When the server audit plugin logs the COM_CHANGE_USER and subsequent queries, it sometimes logs the queries under the old user, and/or sometimes instead of the database value it writes a corrupt value.

      The effect seems to be deterministic for a given build and a set of steps, for example the test case below behaves the same way on all builds that I have on my machine; but it is just empirical, the exact logic when the problem occurs and when it stops happening are so far unclear to me. Maybe there is underlying non-deterministic behavior, or something remains not initialized (although none of ASAN/UBSAN/MSAN complain about anything).

      INSTALL SONAME 'server_audit';
      		 
      SET GLOBAL server_audit_logging=ON;
      		 
      --let $datadir= `select @@datadir`
      		 
       
      		 
      create user foo;
      		 
      --change_user foo
      		 
      SELECT CURRENT_USER() AS should_be_foo;
      		 
      --exec tail -n 2 $datadir/server_audit.log
      		 
      --change_user root
      		 
       
      		 
      --let $restart_parameters= --general_log=OFF --server-audit-logging=ON
      		 
      --source include/restart_mysqld.inc
      		 
       
      		 
      --change_user foo
      		 
      SELECT CURRENT_USER() AS should_be_foo_again;
      		 
      --exec tail -n 2 $datadir/server_audit.log
      		 
      --change_user root
      		 
       
      		 
       
      		 
      drop user foo;
      		 
      UNINSTALL SONAME 'server_audit';

      11.8 cc831f16c82f00d3531e09c2f5c59eadc0abb0d7

      		 
      SELECT CURRENT_USER() AS should_be_foo;
      		 
      should_be_foo
      		 
      foo@%
      		 
      20250326 12:49:16,mesh,,,4,0,CHANGEUSER,,,0
      		 
      20250326 12:49:16,mesh,root,,4,27,QUERY,,'SELECT CURRENT_USER() AS should_be_foo',0
      		 
      # restart: --general_log=OFF --server-audit-logging=ON
      		 
      SELECT CURRENT_USER() AS should_be_foo_again;
      		 
      should_be_foo_again
      		 
      foo@%
      		 
      20250326 12:49:18,mesh,,,3,0,CHANGEUSER,OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO,,0
      		 
      20250326 12:49:18,mesh,foo,localhost,3,8,QUERY,,'SELECT CURRENT_USER() AS should_be_foo_again',0

      So, in the first case after CHANGE_USER the query (SELECT CURRENT_USER()) is still logged under the user "root", even though the user has been changed and the query correctly returns "foo".
      Then we restart the server with the general log disabled (I have no idea why it is relevant, but apparently it is), and try the same CHANGE_USER again. Now the query after the change is correctly logged under "foo", but the CHANGEUSER record itself looks corrupt.

      As said above, I'm getting the same result on all my builds of 10.5..main – release, debug, asan etc. alike.

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-36395 SET SESSION AUTHORIZATION is written in server audit log under the new user

          • Major - Major loss of function.
          • Open

          Activity

            There are no comments yet on this issue.

            People

              holyfoot Alexey Botchkov
              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.