From: | oleg yusim <olegyusim(at)gmail(dot)com> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | John R Pierce <pierce(at)hogranch(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Failing to known state |
Date: | 2016-01-06 01:06:00 |
Message-ID: | CAKd4e_E3+xdaiu=yErV34DxnmU+B3Hb2kx1ktM8oUCwcpQ+wWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Joe,
Exactly how I marked it :)
Thanks,
Oleg
On Tue, Jan 5, 2016 at 6:50 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> On 01/05/2016 04:32 PM, John R Pierce wrote:
> > On 1/5/2016 4:12 PM, oleg yusim wrote:
> >> I meant a scenario, when user is trying to connect to database
> >> (doesn't matter what interface) and database fails at this moment. If
> >> all authentication/authorization/validation functions are written to
> >> return false in case of abnormal termination, we are fine. If not, we
> >> can potentially encounter the situation when database fails into state
> >> where user is given greater privileges than he/she should or even
> >> authenticated, when he/she shouldn't.
> >
> > if the postgres server processes terminate for any reason, there's
> > nothing to connect to. the client application will get a error like
> > 'connection refused' back from the connection attempt, or if it was
> > already connected and the server aborts, the next query will return an
> > error like CONNECTION_BAD. there's no possible privilege elevation.
>
> +1
>
> I think you can call this one "Applicable -- Inherently Meets"
>
> Joe
>
> --
> Crunchy Data - http://crunchydata.com
> PostgreSQL Support for Secure Enterprises
> Consulting, Training, & Open Source Development
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-01-06 01:31:25 | Re: Code of Conduct: Is it time? |
Previous Message | oleg yusim | 2016-01-06 01:05:32 | Re: Failing to known state |