Обсуждение: Re: [HACKERS] Query cancel and OOB data

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

"Maurice Gittens" <mgittens@gits.nl> writes:
> 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".

Well, I think that the cancel security mechanism ought to be per backend
process, not per user.  That is, simply being the same "Postgres user"
should not give you the ability to issue a cancel; you ought to be
required to have some direct association with a particular client/backend
session.  Access to the client/backend connection channel is one way;
knowledge of a per-connection secret is another.

Also, isn't it true that not all the supported authentication mechanisms
use a password?  Taking this approach would mean we have to design a new
cancel security mechanism for each authentication protocol.

            regards, tom lane

>
> "Maurice Gittens" <mgittens@gits.nl> writes:
> > 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".
>
> Well, I think that the cancel security mechanism ought to be per backend
> process, not per user.  That is, simply being the same "Postgres user"
> should not give you the ability to issue a cancel; you ought to be
> required to have some direct association with a particular client/backend
> session.  Access to the client/backend connection channel is one way;
> knowledge of a per-connection secret is another.
>
> Also, isn't it true that not all the supported authentication mechanisms
> use a password?  Taking this approach would mean we have to design a new
> cancel security mechanism for each authentication protocol.

Yes, most connections don't have passwords.  Better to keep cancel
separate.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)