| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
| Date: | 2012-03-27 13:49:25 |
| Message-ID: | 29067.1332856165@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
>> I think the more important question is a policy question: do we want
>> it to work like this?
> The DBA can customize policy by revoking public execute permissions on
> pg_catalog.pg_terminate_backend and interposing a security definer function
> implementing his checks. For the population who will want something different
> here, that's adequate.
I don't particularly trust solutions that involve modifying
system-defined objects. In this case, a dump and reload would be
sufficient to create a security hole, because the REVOKE would go away.
(Now, I'm not particularly concerned about the issue in the first place.
Just pointing out that for someone who is, the above isn't a great
solution.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Shulgin | 2012-03-27 14:13:55 | Re: Another review of URI for libpq, v7 submission |
| Previous Message | Andrew Dunstan | 2012-03-27 13:46:07 | Re: Odd out of memory problem. |