From: | Miles Elam <miles(dot)elam(at)productops(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inserts restricted to a trigger |
Date: | 2019-06-18 16:30:12 |
Message-ID: | CAALojA82fH0Nbb+qKRPJpx_mcdZ1Dh3xQrBk3hTQBbQ9kbcWtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 retaining info about the current user/role?
On Mon, Jun 17, 2019 at 5:47 PM <raf(at)raf(dot)org> wrote:
> 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 the audit information.
> >
> > Would the below not work?:
> > CREATE the table as superuser or other privileged user
> > Have trigger function run as above user(use SECURITY DEFINER)
>
> and make sure not to give any other users insert/update/delete
> permissions on the audit table.
>
> > > Thanks in advance,
> > >
> > > Miles Elam
> >
> > --
> > Adrian Klaver
> > adrian(dot)klaver(at)aklaver(dot)com
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Neyman | 2019-06-18 16:32:56 | RE: Connection refused (0x0000274D/10061) |
Previous Message | Rob Nikander | 2019-06-18 16:20:39 | Is array_append O(n)? |