From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: Cancel key now ready |
Date: | 1998-06-08 19:29:11 |
Message-ID: | 11303.897334151@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> OK, sure, pass the pid. However, one problem is that the postmaster
> does not know the pid until after it forks the backend, so if you want
> to send the pid with the cancel key, you will have to send the pid from
> the backend.
Ah, I see: you were planning to send the cancel authorization data to
the FE as part of the AuthenticationOK message. I was assuming it
should be sent by the backend as part of backend startup.
It could be done either way I suppose. The transmission of the cancel
key to the backend is essentially free (see my recent patch), so really
it boils down to whether we'd rather add version-dependent fields to
AuthenticationOK or just add a whole new message type.
> Also, the odds of two backends have the same cancel key, when random
> returns a long() is so astonomically small, that I am willing to live
> with the risk, to take the advantage of cleaner, more modular code.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Egon Schmid | 1998-06-08 19:33:05 | Re: [HACKERS] Re: Cancel key now ready |
Previous Message | Bruce Momjian | 1998-06-08 19:29:06 | Re: [HACKERS] Re: Cancel key now ready |