On 06/09/2017 08:56 AM, Ken Tanzer wrote: > On Fri, Jun 9, 2017 at 6:42 AM, Joe Conway wrote: > See set_user for a possible solution: https://github.com/pgaudit/ > > Thanks! Looking at the README, it seems like the intended use case is > the opposite (escalating privileges), but if I understand could work anyway? It currently supports both use-cases (but not both simultaneously very well). For your use you can do (from the README): --- Block switching to a superuser role set_user.block_superuser = on --- > If I'm understanding, you could set_user() with a random token and > thereby prevent switching back? Exactly -- in order to switch back the same token would be needed. So assuming you are using persistent connections (connection pooler, etc.) you would start a new user session by calling set_user() with a token, and then reset when done with the same token. Or since "done" may not be something the app can really know, you might end up doing a preemptive reset using the token and then then set_user(). > The extra logging would be undesirable. Is there any way to skip that > entirely? I see with block_log_statement I could dial down the logging > after switching users, but that would require the app to be aware of > what the current "normal" logging level was. Also from the README: --- Notes: If set_user.block_log_statement is set to "off", the log_statement setting is left unchanged. --- So assuming you do not normally have statements being logged, this would not change that. > Any other pitfalls I'm not seeing, or reasons this might be a bad idea? As noted in the README, set_user will refuse to run inside a transaction block, but other than that none that I know of. Of course if you come up with any I'd be very interested to hear about them. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment:
signature.asc
Description: OpenPGP digital signature
