Re: BUG #13854: SSPI authentication failure: wrong realm name used - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: BUG #13854: SSPI authentication failure: wrong realm name used
Date
Msg-id CABUevEyym8eyTPj029rhDvwR1pp2uBAshP9u8D2_EYiHvYg5HQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #13854: SSPI authentication failure: wrong realm name used  (David Steele <david@pgmasters.net>)
Responses Re: BUG #13854: SSPI authentication failure: wrong realm name used
Re: BUG #13854: SSPI authentication failure: wrong realm name used
List pgsql-hackers


On Tue, Mar 29, 2016 at 5:09 PM, David Steele <david@pgmasters.net> wrote:
On 3/24/16 5:22 PM, Alvaro Herrera wrote:
Christian Ullrich wrote:

To be honest, I'm not sure what can and cannot be done in auth code. I
took inspiration from the existing SSPI code and nearly every error
check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already,
directly or via pg_SSPI_error(). If this could cause serious trouble,
someone would have noticed yet.

I think the problem is whether the report is sent to the client or not,
but I may be confusing with something else (COMMERROR reports?).

What *could* happen, anyway? Can ereport(ERROR) in a backend make the
postmaster panic badly enough to force a shared memory reset?

Probably not, since it's running in a backend already at that point, not
in postmaster.

It seems like this patch should be set "ready for committer".  Can one of the reviewers do that if appropriate?

I'll pick it up to do that as well as committing it. 

--

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Robert Haas
Date:
Subject: Re: extend pgbench expressions with functions