Re: [HACKERS] Re: Cancel key now ready

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Re: Cancel key now ready
Дата
Msg-id 199806081934.PAA13229@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: Cancel key now ready  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Egon Schmid
Дата:
Сообщение: Re: [HACKERS] Re: Cancel key now ready
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: Cancel key now ready