From: | oleg yusim <olegyusim(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Failing to known state |
Date: | 2016-01-06 01:05:32 |
Message-ID: | CAKd4e_HqF5Dm7pMheLBWiHNg7Y48h_fY7P+MM5n3c_DAkgk38A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
John,
Thanks, what you are saying makes sense. I agree, it would cause all user
to go through authentication/authorization loop all over and terminate all
running transactions too.
Thanks,
Oleg
On Tue, Jan 5, 2016 at 6:32 PM, John R Pierce <pierce(at)hogranch(dot)com> 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.
>
>
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | oleg yusim | 2016-01-06 01:06:00 | Re: Failing to known state |
Previous Message | Adrian Klaver | 2016-01-06 01:04:48 | Re: Failing to known state |