Re: [HACKERS] Re: Cancel key now ready

> It would only take a few more lines to make it safe: generate a key,
> check for a duplicate in the list of active backends, repeat if there
> is a duplicate. However I think that using PID+key is better, because
> it makes it that much harder for an attacker to guess a valid cancel
> request.

Another way to do it is that when scanning looking for a match of a
cancel key, do not execute the cancel if there is more than one match.
Simple, and we are already scannig the structure. I see no reason to
scan it at cancel assignment time because the odds are so small.

But the PID is clearly visible to an attacker, so I see no benefit. If
it can be sent easily, lets do it. I am not sure where/how to send it,
so do it the way you think is best. Again, if you send the pid, you
can't have duplicates, you are right. Also, remember if we send the
cancel and the pid, we have to store each value in every interface. It
is not just libpq.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)