maria-developers team mailing list archive

[Alexey Botchkov <holyfoot@xxxxxxxxxxxx>]

Hello Sergei, all.

I didn't quite understand what exact changes in 5.5.34 are important to us,
so in order to begin i'm going to mention shortly what is new in MySQL 
5.7 audit plugin API.

1. New event classes added:
    MYSQL_AUDIT_PARSE_CLASS            = 2,
      MYSQL_AUDIT_AUTHORIZATION_CLASS    = 3,
      MYSQL_AUDIT_TABLE_ACCESS_CLASS     = 4,
      MYSQL_AUDIT_GLOBAL_VARIABLE_CLASS  = 5,
      MYSQL_AUDIT_SERVER_STARTUP_CLASS   = 6,
      MYSQL_AUDIT_SERVER_SHUTDOWN_CLASS  = 7,
      MYSQL_AUDIT_COMMAND_CLASS          = 8,
      MYSQL_AUDIT_QUERY_CLASS            = 9,
      MYSQL_AUDIT_STORED_PROGRAM_CLASS   = 10,
These new notifications are sent from various parts of the code. I think 
that part can be most
difficult to keep similar between Maria and My.

New data structures are declared for these classes to send data inside 
notify().
In my opinion these data structures only contain little information, not 
sufficient for many tasks.

2. Plugin can specify the CLASS/SUBCLASS filter in the st_mysql_audit 
structure.
   To implement that nubers of subclasses were changed (i mean 
previously known subclasses).

3. notify() function returns 'int' (it used to be 'void').

   I think 2. and 3. are the reasons MySQL doesn't load plugins with 
older interface.


4. Notification function can affect server.
    - Nonzero return from the notify() breaks the query execution in 
some cases.
       - Query can be modified inside the 'notify' function in some cases.

5. Sending notification looks quite crazy in the code. All 
notification-sending functions share
    the exactly same name 'mysql_audit_notify'. Naturally the number 
and types of parameters are different.
    So that i have complications if i want to find all the places 
where  for instance the MYSQL_AUDIT_PARSE_CLASS
    notifications are sent. 'grep' isn't much help anymore.

6. The code is immature. The MYSQL_AUDIT_TABLE_ACCESS_CLASS just is not 
supported.
      st_mysql_audit::class_mask doesn't always work as it's supposed to.



Now my proposals for our audit API.

The 'radical' proposal :

make the notify() function return 'int'

freeze the AUDIT_INTERFACE_VERSION forever.

notify() expects the 'event_class' as a parameter. It does something 
with the classes it is aware of.
if it gets the class it doesn't know about - it should just return.

notify() at the moment is expected to get the server data from the 
'const void *event' sent to it as a paramter,
Which is in my opinion inconvenient for everybody.
My idea is to provide a set of functions like 
'ap_get_query_string(MYSQL_THD thd, const void *event)', or
'ap_get_connection_id(MYSQL_THD thd, const void *event)'.
That set can be extended in newer versions of the server, but old 
functions never change.
If a plugin connects to the old server where that new possibilities are 
not implemented for some reason,
these function still available, just do nothing.
Plugin can check if some functions are available with the server it 
connected to.


We provide the plugin developer with an 'audit_plugin_adaptor.c' file, 
that is built
inside the plugin. It checks the version of the server that loads the 
plugin and links or
implements the 'ap_*' functions respectively. Also it provides proper 
structures for the
connecting server and interceipts notification's call to prepare it for 
the developer's notify() function.


That way the plugin once built can work with variety of servers. And 
getting newer 'audit_plugin_adaptor.c'
is going to make your plugin working with the newer versions of a server 
(be it MariaDB or MySQL).


Less radical proposition is to mimic MySQL's API, to make the plugin 
compilable both in MySQL and MariaDB
environment. So we get rid of the 'maria_declare_plugin', leaving only 
'mysql_declare_plugin'.
The present idea of having both doesn't work well.


Last option i see - get rid of the 'mysql_declare_plugin', leaving only 
'maria_declare_plugin' and
forget about the idea that same plugin is used in MySQL and MariaDB at 
the same time.
In this case i'd provide the set of the beforementioned 'ap_*' functions 
for the plugin to
get server data. As before i belive it'd be convenient, we'd never need 
to check the plugin
API version, and once built the plugin can work with many versions of 
MariaDB. And
we don't need the 'adaptor.c' file as the proper .h file seem to be enough.


Best regards.
HF