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

Re: pg_signal_backend() asymmetry

From: Noah Misch <noah(at)leadboat(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Josh Kupershmidt <schmiddy(at)gmail(dot)com>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_signal_backend() asymmetry
Date: 2012-06-28 13:48:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jun 28, 2012 at 01:36:49AM -0700, Daniel Farina wrote:
> On Wed, Jun 27, 2012 at 5:38 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> > I have one nitpick related to the recent changes for
> > pg_cancel_backend() and pg_terminate_backend(). If you use these
> > functions as an unprivileged user, and try to signal a nonexistent
> > PID, you get:
> I think the goal there is to avoid leakage of the knowledge or
> non-knowledge of a given PID existing once it is deemed out of
> Postgres' control.  Although I don't have a specific attack vector in
> mind for when one knows a PID exists a-priori, it does seem like an
> unnecessary admission on the behalf of other programs.

I think it was just an oversight.  I agree that these functions have no
business helping users probe for live non-PostgreSQL PIDs on the server, but
they don't do so and Josh's patch won't change that.  I recommend committing
the patch.  Users will be able to probe for live PostgreSQL PIDs, but
pg_stat_activity already provides those.

> Also, in pg_cancel_backend et al, PID really means "database session",
> but as-is the marrying of PID and session is one of convenience, so I
> think any message that communicates more than "that database session
> does not exist" is superfluous anyhow.  Perhaps there is a better
> wording for the time being that doesn't implicate the existence or
> non-existence of the PID?

Perhaps, though I'm not coming up with anything.  The message isn't wrong; the
value is a PID independent of whether some process has that PID.


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-06-28 13:49:36
Subject: Re: [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc
Previous:From: Jon NelsonDate: 2012-06-28 13:47:53
Subject: Re: Posix Shared Mem patch

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