On Thu, Jun 28, 2012 at 01:36:49AM -0700, Daniel Farina wrote: > On Wed, Jun 27, 2012 at 5:38 PM, Josh Kupershmidt <schmi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers