Hi Adrian,
Thank you very much for that link. It confirms what JD and John said, plus
explains couple other moments to me.
Thanks,
Oleg
On Tue, Jan 5, 2016 at 7:04 PM, Adrian Klaver
wrote:
> On 01/05/2016 04:12 PM, oleg yusim wrote:
> > Hi Adrian,
> >
> > I meant a scenario, when user is tryi
Hi Joe,
Exactly how I marked it :)
Thanks,
Oleg
On Tue, Jan 5, 2016 at 6:50 PM, Joe Conway 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)
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 wrote:
> On 1/5/2016 4:12 PM, oleg yusim wrote:
>
> I
On 01/05/2016 04:12 PM, oleg yusim wrote:
> Hi Adrian,
>
> 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 abno
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
>>
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 f
Hi Adrian,
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
Thanks JD.
Let me confirm I got you right. So, by exception you mean the
authentication/authorization/validation functions would return false in
case of DB failure?
Thanks,
Oleg
On Tue, Jan 5, 2016 at 5:33 PM, Joshua D. Drake
wrote:
> On 01/05/2016 03:21 PM, oleg yusim wrote:
>
>> Thanks JD.
On 01/05/2016 03:21 PM, oleg yusim wrote:
Thanks JD.
From what I read about WAL (you have been referring to this:
http://www.postgresql.org/docs/current/static/wal-internals.html
pg_xlog, right?) it allows us to know what happened, but does it
warranty known secure state? I mean, I do not think
On 01/05/2016 03:21 PM, oleg yusim wrote:
Thanks JD.
From what I read about WAL (you have been referring to this:
http://www.postgresql.org/docs/current/static/wal-internals.html
pg_xlog, right?) it allows us to know what happened, but does it
warranty known secure state? I mean, I do not think
Thanks JD.
>From what I read about WAL (you have been referring to this:
http://www.postgresql.org/docs/current/static/wal-internals.html pg_xlog,
right?) it allows us to know what happened, but does it warranty known
secure state? I mean, I do not think it would help with this:
"In general, secu
On 01/05/2016 03:09 PM, oleg yusim wrote:
The question here, what is PostreSQL 9.4.5 (hosted on Linux box)
behavior? Does it fail to known/secure state in these 3 cases? I tried
to find the description of the way PostgreSQL fails in this regard, but
didn't find much.
Based on what you paste
Greetings,
One more security requirement I'm battling with:
The DBMS must fail to a secure state if system initialization fails,
shutdown fails, or aborts fail.
Failure to a known state can address safety or security in accordance with
the mission/business needs of the organization.
Failure t
13 matches
Mail list logo
