When I originally wrote the post on the MySQL Audit Plugin API, the API still wasn't documented, instead I got my information from the source and the samples. Just now, the documentation is available here, with some more specific information here.
I have a bug to report on the Plugin API though, which is that a user with root privileges can possibly uninstall the plugin, which will void any auditing. I'm not 100% how this works yet, but I am certain that for any serious use of auditing, you would possibly want the ability to not being able to unload a plugin. I'll get back to you on this.
/Karlsson
5 comments:
It's certainly not a bug that one can unload a plugin - it's a feature of the plugin interface.
But fear not! MySQL build systems supports statically linked plugins, to perform any serious auditing and to make sure a plugin can not be unloaded you need to build your plugin in mysqld. Simply ./configure --with-plugin-your_audit_plugin
Well, I think auduting is special here. The issue with statically linked plugins is that a server build is necessary. In general, I agree that unloading a Plugin is a feature. As auditing is there to provide auditing of actions taken and hence is a slightly bit different, noone seriously using the AUDIT plugin for auduting would accept that to be turned off by any database user, including root, by the switch of a command.
What I was thinking about was a means of loading a plugin through the commandline/.cnf that would have the same effect as a statically linked plugin. Like the FORCE option, but with the added feature of being non-unloadable.
Alternatively, this could be handled from the deinit function of the plugin. I can think of cases where a plugin really should be allowed to be uninstalled, even if the root user instructs it to be uninstalled. And the deinit function does return a value, but that is currently ignored by the server. Having the server acknowledge the returncode and not uninstall the plugin if the returnvalue is true seems like a simple fix? Or?
This "Audit" stuff documentation looks strangely familiar... :-)
With regard to making an audit plugin un-uninstallable... Obtain a global reference to the plugin soon after init and never release the reference. The plugin can now never be uninstalled. There are many ways this can be done easily using the internal plugins api. However, it won't work on Windows because the required entry point isn't exported.
Antony!
Just what I would need. Although I also think that if the plugin deinit funtion returns a value (and it IS defined to return an int), then that value should do something, that is not unreasonable.
I haven't looked at the plugin API enough to figure out what how to do what you are suggestion, but now I know what to look for at least...
/Karlsson
Originally, the concept was for the deinit routine can return an error to avoid uninstall or EAGAIN if uninstall was in progress... But somewhere along the line, that was removed.
Post a Comment