| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Christian Ullrich <chris(at)chrullrich(dot)net> |
| Cc: | "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-24 21:22:49 |
| Message-ID: | 20160324212249.GA697466@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-03-24 21:40:03 | Re: Breakage with VACUUM ANALYSE + partitions |
| Previous Message | Christian Ullrich | 2016-03-24 20:58:08 | Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-03-24 21:34:51 | Re: Relation extension scalability |
| Previous Message | Petr Jelinek | 2016-03-24 21:12:53 | Re: Sequence Access Method WIP |