From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_terminate_backend for same-role |
Date: | 2012-03-16 06:01:14 |
Message-ID: | CAAZKuFbtA18z3XeFV8Uvw3VoeFPfdU+uxhTn8SFVr3QNwEiJEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 15, 2012 at 10:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)com> writes:
>> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> But actually I don't see what you hope to gain from such a change,
>>> even if it can be made to work. Anyone who can do kill(SIGINT) can
>>> do kill(SIGKILL), say --- so you have to be able to trust the signal
>>> sender. What's the point of not trusting it to verify the client
>>> identity?
>
>> No longer true with pg_cancel_backend not-by-superuser, no?
>
> No. That doesn't affect the above argument in the least. And in fact
> if there's any question whatsoever as to whether unprivileged
> cross-backend signals are secure, they are not going in in the first
> place.
Okay, well, I believe there is a race in handling common
administrative signals that *might* possibly matter. In the past,
pg_cancel_backend was superuser only, which is a lot like saying "only
available to people who can be the postgres user and run kill." The
cancellation packet is handled via first checking the other backend's
BackendKey and then SIGINTing it, leaving only the most narrow
possibility for a misdirected SIGINT.
But it really is unfortunate that I, a user, run a query or have a
problematic connection of my own role and just want the thing to stop,
but I can't do anything about it without superuser. In recognition of
that, pg_cancel_backend now can operate on backends owned by the same
user (once again, checked before the signal is processed by the
receiver, just like with the cancellation packet).
There was some angst (but I'm not sure about how specific or uniform)
to extend such signaling power to pg_terminate_backend, and the only
objection I can think of is there is this race, or so it would seem to
me. Maybe it's too small to care, in which case we can just extend
the same policy to pg_terminate_backend, or maybe it's not, in which
case we could get rid of any signaling race conditions.
The only hypothetical person who would be happy with the current
situation, if characterized correctly, would be one who thinks that
pid-race on SIGINT from non-superusers (long has been true in the form
of the cancellation packet) is okay but on SIGTERM such a race is not.
--
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2012-03-16 07:44:17 | Re: [v9.2] Add GUC sepgsql.client_label |
Previous Message | Tom Lane | 2012-03-16 05:45:45 | Re: pg_terminate_backend for same-role |