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

From Alvaro Herrera
Subject Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
Date
Msg-id 20160329221413.GA929448@alvherre.pgsql
Whole thread Raw
In response to Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > So, it seems that ClientAuthentication() expects to raise ereport(FATAL)
> > in case of authentication failures.  But what's the code path that
> > causes that to happen if a ereport(ERROR) happens in there?  Because all
> > that code is pretty careful to not do ereport(ERROR) directly and
> > instead return STATUS_ERROR which makes ClientAuthentication do the
> > FATAL report.  If this doesn't matter, then isn't this whole code overly
> > complicated for no reason?
> 
> The reason why elog(ERROR) will become a FATAL is that no outer setjmp
> has been executed yet, so elog.c will realize it has noplace to longjmp
> to.

Ah, I was looking callers up-stack and found nothing.  That should have
cued me that that was happening :-)

> Anyway, as things stand, elog(ERROR) will abort the session safely but
> you won't necessarily get the kind of logging you want, so expected
> auth-failure cases should try to go the STATUS_ERROR route.

In other words, the use of palloc() and friends (psprintf in the patch)
should be acceptable here.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Remove TZ entry from postgres CLI doc page.