On Thu, Mar 15, 2012 at 10:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniel Farina <dan...@heroku.com> writes: >> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
