Re: [HACKERS] Re: Cancel key now ready - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Re: Cancel key now ready
Date
Msg-id 199806081934.PAA13229@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: Cancel key now ready  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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@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)

pgsql-hackers by date:

Previous
From: Egon Schmid
Date:
Subject: Re: [HACKERS] Re: Cancel key now ready
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: Cancel key now ready