Re: [HACKERS] Query cancel and OOB data

From: "Maurice Gittens" <mgittens(at)gits(dot)nl>
To: "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <byronn(at)insightdist(dot)com>, <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Query cancel and OOB data
Date: 1998-05-24 11:43:41
Message-ID: 000601bd8709$339e26e0$fcf3b2c2@caleb..gits.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>However, in thinking about it, I don't think there is any way to avoid
>your solution of pid/secret key. The postmaster, on receiving the
>secret key, can send a signal to the backend, and the query will be
>cancelled. Nothing will be sent along the backend/client channel. All
>other interfaces that want cancel handling will have to add some code
>for this too.
>

Assuming that every user has a password which is known by both the client
and the server, it seem to me like using a one-way function based on the
clientuser password as the secret key (refered to above) is appropiate.
This avoids the need for introducing "yet another shared secret into the
system".

A one-way function is expected to make it computationaly infeasible to
deduce the password given the secretkey. One-way functions (SHA1, MD5) are
also quite fast. (If I'm not mistaken these functions are allowed to be
exported
from the US. )

By including a cancel request id (together with the user password) with the
information being hashed (by the one-way function) it is also possible to
detect (and avoid) denial of service attacks
(which are based on replaying the cancel request secret keys).

This does however imply that a certain amount of extra booking is needed.

With regards from Maurice.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1998-05-24 15:29:42 Re: [HACKERS] Query cancel and OOB data
Previous Message Tom Ivar Helbekkmo 1998-05-24 11:43:05 Re: [HACKERS] Current sources?