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

Add audit plugin API functions to disable/enable specific audit plugins

Details

    Description

      When server_audit_logging=OFF is set, MariaDB Server's Audit Plugin API hooks still call the server_audit plugin's callback functions. This caused performance issues in MDEV-18661 / MDEV-19174.

      To prevent issues like this, maybe it would make sense to add a couple audit plugin API functions that can be used to disable/enable specific audit plugins. For example:

      bool mysql_audit_disable_plugin(plugin_ref);
      bool mysql_audit_enable_plugin(plugin_ref);
      

      That way, if the user sets server_audit_logging=OFF, then the server_audit plugin can tell the audit plugin API to disable its callback functions. And then if the user sets server_audit_logging=ON, then the plugin can tell the audit plugin API to enable its callback functions again.

      Attachments

        Issue Links

          Activity

            MDEV-18661 and MDEV-19174 are closed now. Is it still an issue?

            I don't think there should be a way to disable auditing at all. Not even server_audit_logging=OFF.
            If one wants not to audit, one can uninstall the plugin and server_audit_logging=OFF isn't really needed.
            If the plugin had FORCE_AND_PERMANENT this implies that one should not be able to disable auditing, so server_audit_logging=OFF shouldn't even work.

            serg Sergei Golubchik added a comment - MDEV-18661 and MDEV-19174 are closed now. Is it still an issue? I don't think there should be a way to disable auditing at all. Not even server_audit_logging=OFF . If one wants not to audit, one can uninstall the plugin and server_audit_logging=OFF isn't really needed. If the plugin had FORCE_AND_PERMANENT this implies that one should not be able to disable auditing, so server_audit_logging=OFF shouldn't even work.
            GeoffMontee Geoff Montee (Inactive) added a comment - - edited

            Hi serg,

            MDEV-18661 and MDEV-19174 are closed now. Is it still an issue?

            I think the bug is fixed. I heard positive feedback about the test builds that contained the fix, and I haven't heard any complaints yet about last week's releases which also contained the fix.

            The reason that I created this Jira issue was that I discussed the bug with claudio.nanni and wagnerbianchi, and they were surprised that the plugin still seemed to be doing work when server_audit_logging=OFF was set. They seemed to have the opinion that the plugin shouldn't do anything in this scenario. They thought that you should be able to stop the plugin from doing work without being forced to uninstall it.

            In my opinion, the current design is probably fine, as long as the plugin's callback functions are designed to have minimal overhead when server_audit_logging=OFF is set. I think that may be true now that MDEV-18661 and MDEV-19174 are fixed.

            I don't think there should be a way to disable auditing at all. Not even server_audit_logging=OFF.
            If one wants not to audit, one can uninstall the plugin and server_audit_logging=OFF isn't really needed.

            Oh, you think that allowing the option to disable audit logging with server_audit_logging=OFF was bad design to begin with?

            I checked the documentation for the MySQL Enterprise Audit plugin, and it doesn't look like that plugin have this capability, so MySQL's engineering team might agree with you.

            https://dev.mysql.com/doc/refman/8.0/en/audit-log-installation.html

            https://dev.mysql.com/doc/refman/8.0/en/audit-log-logging-configuration.html

            https://dev.mysql.com/doc/refman/8.0/en/audit-log-reference.html#audit-log-option-variable-reference

            It doesn't looks like Percona's audit plugin has this capability either.

            https://www.percona.com/doc/percona-server/8.0/management/audit_log_plugin.html

            If the plugin had FORCE_AND_PERMANENT this implies that one should not be able to disable auditing, so server_audit_logging=OFF shouldn't even work.

            Good point. Would you consider that a bug?

            GeoffMontee Geoff Montee (Inactive) added a comment - - edited Hi serg , MDEV-18661 and MDEV-19174 are closed now. Is it still an issue? I think the bug is fixed. I heard positive feedback about the test builds that contained the fix, and I haven't heard any complaints yet about last week's releases which also contained the fix. The reason that I created this Jira issue was that I discussed the bug with claudio.nanni and wagnerbianchi , and they were surprised that the plugin still seemed to be doing work when server_audit_logging=OFF was set. They seemed to have the opinion that the plugin shouldn't do anything in this scenario. They thought that you should be able to stop the plugin from doing work without being forced to uninstall it. In my opinion, the current design is probably fine, as long as the plugin's callback functions are designed to have minimal overhead when server_audit_logging=OFF is set. I think that may be true now that MDEV-18661 and MDEV-19174 are fixed. I don't think there should be a way to disable auditing at all. Not even server_audit_logging=OFF. If one wants not to audit, one can uninstall the plugin and server_audit_logging=OFF isn't really needed. Oh, you think that allowing the option to disable audit logging with server_audit_logging=OFF was bad design to begin with? I checked the documentation for the MySQL Enterprise Audit plugin, and it doesn't look like that plugin have this capability, so MySQL's engineering team might agree with you. https://dev.mysql.com/doc/refman/8.0/en/audit-log-installation.html https://dev.mysql.com/doc/refman/8.0/en/audit-log-logging-configuration.html https://dev.mysql.com/doc/refman/8.0/en/audit-log-reference.html#audit-log-option-variable-reference It doesn't looks like Percona's audit plugin has this capability either. https://www.percona.com/doc/percona-server/8.0/management/audit_log_plugin.html If the plugin had FORCE_AND_PERMANENT this implies that one should not be able to disable auditing, so server_audit_logging=OFF shouldn't even work. Good point. Would you consider that a bug?
            claudio.nanni Claudio Nanni added a comment -

            I think this is the main point to me:

            Claudio Nanni and Wagner Bianchi, and they were surprised that the plugin still seemed to be doing work when server_audit_logging=OFF was set.

            As reported by Wagner in such situation the plugin was doing a lot of work so much that he had to uninstall it to avoid impact on the server.

            So at that point I have supposed that `server_audit_logging=OFF` was meant to stop writing to log but not stop the background audit job, while it seems after all that's not the case (it should actually stop audit activity) and the background work was consequence of some bugs.

            In general I think it's good to be able to disable a plugin, and apparently Sergei suggests that it's the job of `UNINSTALL.
            If that's safely done by using `UNINSTALL` I'm fine with that, but I don't know if uninstalling plugins on running production servers is always a safe operation.
            Again, this is a general statement and probably it may make sense or not depending on the type of plugin.

            claudio.nanni Claudio Nanni added a comment - I think this is the main point to me: Claudio Nanni and Wagner Bianchi, and they were surprised that the plugin still seemed to be doing work when server_audit_logging=OFF was set. As reported by Wagner in such situation the plugin was doing a lot of work so much that he had to uninstall it to avoid impact on the server. So at that point I have supposed that `server_audit_logging=OFF` was meant to stop writing to log but not stop the background audit job, while it seems after all that's not the case (it should actually stop audit activity) and the background work was consequence of some bugs. In general I think it's good to be able to disable a plugin, and apparently Sergei suggests that it's the job of `UNINSTALL. If that's safely done by using `UNINSTALL` I'm fine with that, but I don't know if uninstalling plugins on running production servers is always a safe operation. Again, this is a general statement and probably it may make sense or not depending on the type of plugin.

            Hi wagnerbianchi,

            The request to have a GLOBAL server_audit system variable is to stop all the background activities, even after you disable the logging part.

            SET GLOBAL server_audit=OFF is helpful and should be considered if possible. I don't want to remove the plugin; I would like to stop the plugin activities completely while we check if it's possible to have it back or not during a problem.

            When the server_audit option is set to OFF at startup, it prevents the plugin from being loaded. If this option were somehow made into a system variable (as requested by MDEV-20226), then the effect would most likely be to unload the plugin, which is basically the same as "removing the plugin", which is something that you say that you don't want to do, so I don't think that this would actually meet your requirements.

            It sounds like what you actually want is for the plugin to have minimal overhead when server_audit_logging=OFF is set. That should be the case now that MDEV-18661 and MDEV-19174 are fixed. Have you checked whether everything is working properly in the latest releases?

            GeoffMontee Geoff Montee (Inactive) added a comment - Hi wagnerbianchi , The request to have a GLOBAL server_audit system variable is to stop all the background activities, even after you disable the logging part. SET GLOBAL server_audit=OFF is helpful and should be considered if possible. I don't want to remove the plugin; I would like to stop the plugin activities completely while we check if it's possible to have it back or not during a problem. When the server_audit option is set to OFF at startup, it prevents the plugin from being loaded. If this option were somehow made into a system variable (as requested by MDEV-20226 ), then the effect would most likely be to unload the plugin, which is basically the same as "removing the plugin", which is something that you say that you don't want to do, so I don't think that this would actually meet your requirements. It sounds like what you actually want is for the plugin to have minimal overhead when server_audit_logging=OFF is set. That should be the case now that MDEV-18661 and MDEV-19174 are fixed. Have you checked whether everything is working properly in the latest releases?

            People

              serg Sergei Golubchik
              GeoffMontee Geoff Montee (Inactive)
              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.