Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally tracking SELECT statements #49

Open
igormq opened this issue May 6, 2022 · 4 comments
Open

Optionally tracking SELECT statements #49

igormq opened this issue May 6, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@igormq
Copy link

igormq commented May 6, 2022

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?
@maltoe
Copy link
Collaborator

maltoe commented Jun 1, 2022

@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
Copy link
Collaborator

maltoe commented Jun 12, 2022

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 maltoe added the enhancement New feature or request label Jun 23, 2022
@maltoe maltoe changed the title Option to track also all data reads for audit logging purporses Optionally tracking SELECT statements Oct 11, 2022
@maltoe
Copy link
Collaborator

maltoe commented Oct 11, 2022

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

@igormq
Copy link
Author

igormq commented Oct 23, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants