Re: pg_signal_backend() asymmetry

On Thu, Jun 28, 2012 at 10:36 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Wed, Jun 27, 2012 at 5:38 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
>> Hi all,
>>
>> 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.

Well, there are two sides to it - one is the message, the other is if
it should be ERROR or WARNING. My reading is that Josh is suggesting
we make them WARNING in both cases, right?

It should be possible to make it a WARNING without leaking information
in the error message..

> 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?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/