| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "chap(at)anastigmatix(dot)net" <chap(at)anastigmatix(dot)net>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
| Subject: | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
| Date: | 2021-07-26 21:30:45 |
| Message-ID: | 217734.1627335045@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2021-Jul-26, Tom Lane wrote:
>> Uh, why not? If you own the trigger, you can drop it, so why shouldn't
>> you be able to temporarily disable it?
> I think an auditing system that can be turned off by the audited user is
> pretty much useless. Or did I misunderstood what you are suggesting?
For auditing purposes, you make a trusted role that owns the trigger,
and is a member of the roles whose actions are to be audited (but NOT
vice versa). I think that any idea that the auditing role doesn't
need to be trusted that much is foolhardy. What we can buy here is
not requiring the auditing role to be full superuser ... assuming that
you don't need auditing of superusers.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-07-26 21:33:19 | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
| Previous Message | Tom Lane | 2021-07-26 21:25:27 | Re: automatically generating node support functions |