carbonite icon indicating copy to clipboard operation
carbonite copied to clipboard

Optionally tracking SELECT statements

Open igormq opened this issue 2 years ago • 4 comments

Hello there,

First of all, thank you so much for this amazing library. It has been a real relief to us of having this!

Right now, the carbonite tracks down all the mutations in the database (insert, update, and delete), but we don't have an option of (optionally) tracking down all the reads for audit logging purposes (e.g. know which user has read which data). My questions are:

  1. Are you folks planning on adding this capability?
  2. If not, do you have an interest in having it?

igormq avatar May 06 '22 18:05 igormq

@igormq Thanks for the kind words and sorry for the delay.

SELECT statements kind of fall in the same category as TRUNCATE ones: So far we've avoided them because they're table-level statements, not row-level, and hence don't really fit nicely into Carbonite's model. So adding support for them would at least mean to come up with a new storage model, IMO, something like queries? So to answer your questions:

  1. No, so far we haven't had the use-case and are not planning on adding this capability.
  2. Sure! If it can be nicely integrated and made optional.

Best, malte

maltoe avatar Jun 01 '22 12:06 maltoe

Just some ideas/thoughts:

  • Probably store the queries in a new table statements, so the name also makes sense for TRUNCATE
  • I'd prefer to extend the existing trigger function with new logic for statements, mostly because it has the config loading and skipping logic already in place. Could be convinced otherwise though, as the rest of the function's logic will be quite different from the row-level function. Maybe it's also possible to split these up, i.e. have one top-level trigger function that loads the config and evaluates the skip conditions and such, and two nested functions, one for row-level, one for statements.
  • For the trigger itself, add a new install_statement_trigger function?
  • I'd like to be able to enable/disable statement auditing per table, too, so I'd suggest to add another field statements (bool, null false, default false) to the triggers table?

maltoe avatar Jun 12 '22 13:06 maltoe

Hey @igormq - just curious, how did you proceed with your read auditing requirement?

maltoe avatar Oct 11 '22 10:10 maltoe

Hey @maltoe, sorry I didn't but I will still have plans to work on this one :)

igormq avatar Oct 23 '22 20:10 igormq