On 6/20/19 3:30 PM, Miles Elam wrote:
Thanks for the reply, Adrian.
1. The audit tables (plural) are recording the historical data for a
table, ie., updates and deletes. All the same data as found in a given
table along with the role that performed the operation, the transaction
id, and the t
Thanks for the reply, Adrian.
1. The audit tables (plural) are recording the historical data for a table,
ie., updates and deletes. All the same data as found in a given table along
with the role that performed the operation, the transaction id, and the
time range where this data was in active use
On 6/19/19 3:07 PM, Miles Elam wrote:
Hi Adrian, thanks for responding.
How would I restrict access to the SECURITY DEFINER function? If it can
be called by the trigger, it can be called by the user as well I would
think. Same issue as access to the table itself only now with a
superuser inte
On 6/19/19 3:07 PM, Miles Elam wrote:
Hi Adrian, thanks for responding.
How would I restrict access to the SECURITY DEFINER function? If it can
be called by the trigger, it can be called by the user as well I would
think. Same issue as access to the table itself only now with a
superuser inte
Hi Adrian, thanks for responding.
How would I restrict access to the SECURITY DEFINER function? If it can be
called by the trigger, it can be called by the user as well I would think.
Same issue as access to the table itself only now with a superuser
intermediary, right?
On Tue, Jun 18, 2019 at
On 6/18/19 10:14 AM, Miles Elam wrote:
Thanks for the suggestion. Unfortunately we only have a single login
role (it's a web app) and then we SET ROLE according to the contents of
a JSON Web Token. So we end up with SESSION_USER as the logged in user
and the active role as CURRENT_USER.
Have
Thanks for the suggestion. Unfortunately we only have a single login role
(it's a web app) and then we SET ROLE according to the contents of a JSON
Web Token. So we end up with SESSION_USER as the logged in user and the
active role as CURRENT_USER.
It may be that we're just stuck with a gap and ne
Have you tried session_user?
create function xx() returns table (cur text, sess text)
security definer language sql as $$
select current_user::text, session_user::text;
$$;
Then log in as different user and:
=> select (xx()).*;
cur| sess
--+---
postgres | write
On Tue,
That seems straightforward. Unfortunately I also want to know the user/role
that performed the operation. If I use SECURITY DEFINER, I get the
superuser account back from CURRENT_USER, not the actual user.
Sorry, should have included that in the original email. How do I restrict
access while still
Adrian Klaver wrote:
> On 6/17/19 4:54 PM, Miles Elam wrote:
> > Is there are way to restrict direct access to a table for inserts but
> > allow a trigger on another table to perform an insert for that user?
> >
> > I'm trying to implement an audit table without allowing user tampering
> > with t
On 6/17/19 4:54 PM, Miles Elam wrote:
Is there are way to restrict direct access to a table for inserts but
allow a trigger on another table to perform an insert for that user?
I'm trying to implement an audit table without allowing user tampering
with the audit information.
Would the below
Is there are way to restrict direct access to a table for inserts but allow
a trigger on another table to perform an insert for that user?
I'm trying to implement an audit table without allowing user tampering with
the audit information.
Thanks in advance,
Miles Elam
12 matches
Mail list logo
