From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Christian Ullrich <chris(at)chrullrich(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
Date: | 2016-03-29 21:52:05 |
Message-ID: | 30297.1459288325@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-03-29 22:14:13 | Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
Previous Message | Alvaro Herrera | 2016-03-29 21:40:32 | Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-03-29 22:06:05 | Re: pg_restore casts check constraints differently |
Previous Message | Thomas Munro | 2016-03-29 21:47:53 | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |