Re: [HACKERS] Query cancel and OOB data
От | Maurice Gittens |
---|---|
Тема | Re: [HACKERS] Query cancel and OOB data |
Дата | |
Msg-id | 000601bd8709$339e26e0$fcf3b2c2@caleb..gits.nl обсуждение исходный текст |
Ответы |
Re: [HACKERS] Query cancel and OOB data
|
Список | 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.
В списке pgsql-hackers по дате отправления: