Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used
Дата
Msg-id 30297.1459288325@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [BUGS] Re: BUG #13854: SSPI authentication failure: wrong realm name used