Skip site navigation (1) Skip section navigation (2)

Re: pg_terminate_backend and pg_cancel_backend by not administrator user

From: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
To: Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>
Cc: Torello Querci <tquerci(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_terminate_backend and pg_cancel_backend by not administrator user
Date: 2011-02-27 21:00:12
Message-ID: AANLkTike=aUo2A6HDmkep99u5p4RiGywjmgn82-6T09p@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Feb 14, 2011 at 8:58 AM, Anssi Kääriäinen
<anssi(dot)kaariainen(at)thl(dot)fi> wrote:
> On 02/14/2011 02:10 PM, Torello Querci wrote:
>>
>> I suppose that give the right to the owner db user to terminate or
>> cancel other session connected to the database which it is owner is a
>> good thing.
>> I not see any security problem because this user can cancel or
>> terminate only the session related with the own database,
>> but if you think that this is a problem, a configuration parameter can be
>> used.
>
> For what it's worth, a big +1 from me. We have pretty much the same use
> case.
>
> It would be good if you could also terminate your own connections.

The superuser-only restriction for pg_cancel_backend() has been a pet
peeve of mine as well. I actually posted a patch a while back to let
users pg_cancel_backend() their own queries, see:
http://archives.postgresql.org/pgsql-admin/2010-02/msg00052.php

IMO it'd be better to do away with this patch's check of:
        /* If the user not is the superuser, need to be the db owner. */

and instead just check if the target session's user matches that of
the cancel requester.

Additionally, this patch keeps all the permission checking inside
pg_signal_backend(). That's fine if we're sure that we want
pg_cancel_backend() and pg_terminate_backend() to undergo the same
permissions check, but perhaps it's a bad idea to relax the
permissions check on pg_terminate_backend() ?

Josh

In response to

pgsql-hackers by date

Next:From: David FetterDate: 2011-02-27 21:25:57
Subject: Re: [COMMITTERS] pgsql: Refactor the executor's API to support data-modifying CTEs bette
Previous:From: Jaime CasanovaDate: 2011-02-27 20:54:49
Subject: sync_rep patch v18

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group