Thread: 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)