From: | Joel Jacobson <joel(at)trustly(dot)com> |
---|---|
To: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
Cc: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: autonomous transactions |
Date: | 2016-09-01 18:19:26 |
Message-ID: | CAASwCXcvwsndWguEga97p5eHikwGQ5D0eLqHWxymr-1SHC8rKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 1, 2016 at 12:12 AM, Vik Fearing <vik(at)2ndquadrant(dot)fr> wrote:
> Part of what people want this for is to audit what people *try* to do.
> We can already audit what they've actually done.
>
> With your solution, we still wouldn't know when an unauthorized attempt
> to do something happened.
The unauthorized attempt to execute the function will still be logged
to the PostgreSQL log file
since it would throw an error, just like trying to connect with e.g.
an invalid username would be logged to the log files.
I think that's enough for that use-case, since it's arguably not an
application layer problem,
since no part of the code was ever executed.
But if someone tries to execute a function where one of the input params
is a password and the function raises an exception if the password
is incorrect and wants to log the unauthorized attempt, then that
would be a good example of when you could use and would need to use
autonomous transactions to log the invalid password attempt.
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2016-09-01 18:35:13 | Re: autonomous transactions |
Previous Message | Tom Lane | 2016-09-01 18:17:33 | Re: \timing interval |