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@gmail.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.
Thanks,
nm
