Re: [HACKERS] Query cancel and OOB data

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