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

From Tom Lane
Subject Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
Date
Msg-id 30297.1459288325@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
List pgsql-hackers
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.

Whether it's overcomplicated I dunno.  I think the idea behind returning
STATUS_ERROR is to allow a centralized reporting site to decorate the
errors with additional info, as indeed auth_fail does.  Certainly that
could be done another way (errcontext?), but that's the way we've got.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Next
From: Alvaro Herrera
Date:
Subject: Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used