Re: [HACKERS] Query cancel and OOB data
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Query cancel and OOB data |
Дата | |
Msg-id | 24853.895850391@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Query cancel and OOB data (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Query cancel and OOB data
|
Список | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.us> writes: > OK, I think I have a solution. I recommend we pass the backend pid to > the client as part of connection startup. Then, when the client wants > to cancel a query, it sends a cancel packet to its backend (new packet > type), and then sends that pid to the postmaster with a new packet type. > When the postmaster receives the packet with the pid, it sends a signal > to that pid/backend. The backend does a recv(MSG_PEEK) to see if it has > a pending packet with a cancel request. If it does, it cancels, if not, > it ignores it. In the read loop of the backend, all cancel requests are > ignored. OK, I guess the point of sending the normal-channel packet is to authenticate the cancel request? Otherwise anyone could send a cancel request to the postmaster, if they know the backend PID. I see a few flaws however: 1. What if the postmaster/signal/backend path is completed before the normal-channel cancel packet arrives? The backend looks, sees no packet, and ignores the request. Oops. This scenario is not at all implausible across a remote connection, since the first transmission of the normal-channel packet might be lost to a data glitch. By the time the client-side TCP stack decides to retransmit, it's too late. 2. I don't think you could use this to abort out of a COPY IN transfer, because the confirmation packet would be impossible to distinguish from data reliably. In general there's a risk of confusion if the server might be looking for the confirmation packet when the client thinks it's in the middle of sending a regular request. 3. There's still a possibility of a denial-of-service attack. A bad guy could send a flood of cancel requests with the right PID, and he'd slow down the server substantially even if nothing ever gets cancelled. (Also, because of point 2, some of the forged cancels might succeed...) > This does a few things for us. It allows us to use cancel in unix > domain sockets, and in Java or anything that can't support OOB. In > fact, I would recommend discarding OOB in favor of this method. The real advantage of OOB for this purpose is that there's no possibility of confusing the cancel request with normal data. I still like the idea I floated a couple days ago: have the initial handshake provide both the PID of the backend and a "secret code" randomly generated by the server for that connection. The client must transmit both the PID and the code to the postmaster for the cancel request to be accepted. That method has all the advantages: 1. The client doesn't have to supply a password; libpq will retain all the necessary info internally. 2. The probability of defeating the scheme can be made arbitrarily small (much smaller than guessing a password, say) with a long enough secret code. 8 or so random bytes ought to do. 3. There's no problem with synchronization between the client/postmaster and client/backend data paths, because no data need be sent across the client/backend path. This is just as good as using OOB to keep the cancel separate from normal traffic. 4. Don't have to depend on having OOB facility. The only disadvantage I can see is having to open a new postmaster connection every time you want to cancel; but hopefully that won't be very often, so performance shouldn't be much of an issue. regards, tom lane
В списке pgsql-hackers по дате отправления: