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