Re: pg_terminate_backend and pg_cancel_backend by not administrator user

From: Noah Misch <noah(at)leadboat(dot)com>
To: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
Cc: Torello Querci <tquerci(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_terminate_backend and pg_cancel_backend by not administrator user
Date: 2011-06-01 21:55:46
Message-ID: 20110601215546.GA8246@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
> On Sun, May 29, 2011 at 5:04 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > What risks arise from unconditionally allowing these calls for the same user's
> > backends? ?`pg_cancel_backend' ought to be safe enough; the user always has
> > access to the standard cancellation protocol, making the SQL interface a mere
> > convenience (albeit a compelling one). ?`pg_terminate_backend' does open up
> > access to a new behavior, but no concrete risks come to mind.
>
> Looking around, I see there were real problems[1] with sending SIGTERM
> to individual backends back in 2005 or so, and pg_terminate_backend()
> was only deemed safe enough to put in for 8.4 [2]. So expanding
> pg_terminate_backend() privileges does make me a tad nervous.

The documentation for the CREATE USER flag would boil down to "omit this flag
only if you're worried about undiscovered PostgreSQL bugs in this area". I'd
echo Tom's sentiment from the first thread, "In any case I think we have to
solve it, not create new mechanisms to try to ignore it."

> Reading through those old threads made me realize this patch would
> give database owners the ability to kill off autovacuum workers. Seems
> like we'd want to restrict that power to superusers.

Would we? Any old user can already stifle VACUUM by holding a transaction open.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2011-06-01 22:02:07 Re: Another issue with invalid XML values
Previous Message Ross J. Reedstrom 2011-06-01 21:53:15 Re: [PERFORM] Hash Anti Join performance degradation