Re: [Maria-developers] new PLUGIN API.
Hi, Alexey! On Oct 25, Alexey Botchkov wrote: > To me both approaches are like indistingushable. The 'service' is too > just the set of callback methods. I don't know if we should keep that > 'plugin type' specification or not, the very idea is getting server's > data and sending commands to server using the callback functions. Right. That's why I pointed out that one can implement this idea as a service or as an audit plugin api. Whatever provides a better fit. > That way plugins get free from the API versions, and the server > is free from fixed structures to send/get data to/from the plugin. > > If we need we can limit the access to the 'audit service' to only these > plugins registered with the AUDIT type. That would be *very* confusing. Services is something any plugin can use. If you want something to be accessible to only AUDIT plugins, this should be part of the plugin_audit.h, not service_audit.h, so to speak. For an example, see how authentication plugin API is defined. A plugin provides the authenticate_user() method. This method gets MYSQL_PLUGIN_VIO as an argument. And the plugin uses MYSQL_PLUGIN_VIO methods (callbacks) to communicate with the client. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] new PLUGIN API.
To me both approaches are like indistingushable. The 'service' is too just the set of callback methods. I don't know if we should keep that 'plugin type' specification or not, the very idea is getting server's data and sending commands to server using the callback functions. That way plugins get free from the API versions, and the server is free from fixed structures to send/get data to/from the plugin. If we need we can limit the access to the 'audit service' to only these plugins registered with the AUDIT type. There will be other limitations anyway. The server data can be accessible in some context inside the audit_notify functions for example) but not accessible in another. Best regards. HF 23.10.2016 15:55, Sergei Golubchik wrote: Hi, Alexey! On Oct 23, Alexey Botchkov wrote: Hi, Sergei. I'd like to draw your attention to this old issue: https://jira.mariadb.org/browse/MDEV-7389 The idea was to make a bigger thing - to modify the plugin API so it is easier to use and let user to do more. Particularly to notify warnings to the audit plugins for this 7389 task. That was done with this task: https://jira.mariadb.org/browse/MDEV-5313 Just to refresh our memory: I proposed to get rid off the API versions and version-dependent memory structures that are used to transfer data to and from the plugin. All we need to do is adding new 'audit_plugin_service'. Which is just the normal service that offer methods to the auditing plugin to send commands to the server and get the server data. You can look at the patch http://lists.askmonty.org/pipermail/commits/2016-February/009025.html So, Serg, do you have anything to say on that subject? Well... First, I'll say that I'm sorry for not replying earlier :) Now, "service" is a server functionality provided openly to all plugins. Kind of a utility library, like alloc() or printf(). Moving audit to a service, means there is no longer audit plugin type (we won't remove it, but it becomes useless) because any plugin can use audit functionality. Is that what we want? Audit is not a general-purpose thing. May be you mean that we should deprecate all plugin types and move everything to services (not now, but over time)? That one possible approach. But just moving audit to a service is not very logical. Another approach would be to keep audit plugin as a *type*, but still use your callback approach. That's fine, callbacks don't need to be done via services, there are plugin-type-specific callbacks too. In that case an audit plugin will get some kind of an audit handler from the server, and will invoke its audit methods, for example audit_handler->get_database(thd); etc. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] new PLUGIN API.
Hi Alexey,
Just soem thought from my side...
> +const char *ap_get_database(MYSQL_THD thd)
> +{
> + if (!thd)
> +return "";
> +
> + return thd->db;
> +}
I think this should be benchmarked with perf. Things like this ain't good
performance wise (we already fixed a bunch of those). That is when function call
convention is more expensive than payload. Especially if you call this many
times per query.
Check for thd != NULL is not performance wise either (because payload is really
small). I believe that thd must be set in all cases: auditing something that
doesn't have context sounds a bit strange.
> + uint audit_event_code;
> + const void *audit_event_data;
Why? Just to avoid passing this as an argument? Though these are normally just
12 bytes, (FWICS) you only need them for a very short duration. All other time
it's just waste of memory. It's not a problem alone, but THD is already way too
overloaded by things like this. This point was originally risen by Vicentiu
back in Amsterdam.
In a nutshell, performance wise it is best if there's just one function call per
event.
Regards,
Sergey
On Sun, Oct 23, 2016 at 01:16:07PM +0400, Alexey Botchkov wrote:
> Hi, Sergei.
>
> I'd like to draw your attention to this old issue:
> https://jira.mariadb.org/browse/MDEV-7389
>
> The idea was to make a bigger thing - to modify the plugin API
> so it is easier to use and let user to do more. Particularly to
> notify warnings to the audit plugins for this 7389 task.
> That was done with this task: https://jira.mariadb.org/browse/MDEV-5313
>
> Just to refresh our memory:
> I proposed to get rid off the API versions and version-dependent
> memory structures that are used to transfer data to and from the plugin.
> All we need to do is adding new 'audit_plugin_service'. Which is
> just the normal service that offer methods to the auditing plugin to
> send commands to the server and get the server data. You can look at the
> patch http://lists.askmonty.org/pipermail/commits/2016-February/009025.html
>
> So, Serg, do you have anything to say on that subject?
>
> Best regards.
> HF
>
>
> ___
> Mailing list: https://launchpad.net/~maria-developers
> Post to : maria-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maria-developers
> More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] new PLUGIN API.
Hi, Alexey! On Oct 23, Alexey Botchkov wrote: > Hi, Sergei. > > I'd like to draw your attention to this old issue: > https://jira.mariadb.org/browse/MDEV-7389 > > The idea was to make a bigger thing - to modify the plugin API > so it is easier to use and let user to do more. Particularly to > notify warnings to the audit plugins for this 7389 task. > That was done with this task: https://jira.mariadb.org/browse/MDEV-5313 > > Just to refresh our memory: > I proposed to get rid off the API versions and version-dependent > memory structures that are used to transfer data to and from the plugin. > All we need to do is adding new 'audit_plugin_service'. Which is > just the normal service that offer methods to the auditing plugin to > send commands to the server and get the server data. You can look at the > patch http://lists.askmonty.org/pipermail/commits/2016-February/009025.html > > So, Serg, do you have anything to say on that subject? Well... First, I'll say that I'm sorry for not replying earlier :) Now, "service" is a server functionality provided openly to all plugins. Kind of a utility library, like alloc() or printf(). Moving audit to a service, means there is no longer audit plugin type (we won't remove it, but it becomes useless) because any plugin can use audit functionality. Is that what we want? Audit is not a general-purpose thing. May be you mean that we should deprecate all plugin types and move everything to services (not now, but over time)? That one possible approach. But just moving audit to a service is not very logical. Another approach would be to keep audit plugin as a *type*, but still use your callback approach. That's fine, callbacks don't need to be done via services, there are plugin-type-specific callbacks too. In that case an audit plugin will get some kind of an audit handler from the server, and will invoke its audit methods, for example audit_handler->get_database(thd); etc. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] new PLUGIN API.
Hi, Sergei. I'd like to draw your attention to this old issue: https://jira.mariadb.org/browse/MDEV-7389 The idea was to make a bigger thing - to modify the plugin API so it is easier to use and let user to do more. Particularly to notify warnings to the audit plugins for this 7389 task. That was done with this task: https://jira.mariadb.org/browse/MDEV-5313 Just to refresh our memory: I proposed to get rid off the API versions and version-dependent memory structures that are used to transfer data to and from the plugin. All we need to do is adding new 'audit_plugin_service'. Which is just the normal service that offer methods to the auditing plugin to send commands to the server and get the server data. You can look at the patch http://lists.askmonty.org/pipermail/commits/2016-February/009025.html So, Serg, do you have anything to say on that subject? Best regards. HF ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
