Re: pg_terminate_backend for same-role

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: pg_terminate_backend for same-role
Дата
Msg-id CAAZKuFbtA18z3XeFV8Uvw3VoeFPfdU+uxhTn8SFVr3QNwEiJEw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_terminate_backend for same-role  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_terminate_backend for same-role
Список pgsql-hackers
On Thu, Mar 15, 2012 at 10:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Farina <daniel@heroku.com> writes:
>> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_terminate_backend for same-role
Следующее
От: Ants Aasma
Дата:
Сообщение: Re: pg_upgrade and statistics