Failing to known state

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 pasted, PostgreSQL does fail to a known state. That is
the whole point of the xlog.

Sincerely,

JD

Thanks,

Oleg

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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, security mechanisms should be designed so that a failure will
follow the same execution path as disallowing the operation. For example,
application security methods, such as isAuthorized(), isAuthenticated(),
and validate(), should all return false if there is an exception during
processing. If security controls can throw exceptions, they must be very
clear about exactly what that condition means. "

Right?

Thanks,

Oleg

On Tue, Jan 5, 2016 at 5:14 PM, Joshua D. Drake <jd@commandprompt.com>
wrote:

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 it would help with this:

"In general, security mechanisms should be designed so that a failure
will follow the same execution path as disallowing the operation. For
example, application security methods, such as isAuthorized(),
isAuthenticated(), and validate(), should all return false if there is
an exception during processing. If security controls can throw
exceptions, they must be very clear about exactly what that condition
means. "

You are correct, that isn't the pg_xlog but yes, PostgreSQL will throw
an exception in those types of cases.

Sincerely,

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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 it would help with this:

"In general, security mechanisms should be designed so that a failure
will follow the same execution path as disallowing the operation. For
example, application security methods, such as isAuthorized(),
isAuthenticated(), and validate(), should all return false if there is
an exception during processing. If security controls can throw
exceptions, they must be very clear about exactly what that condition
means. "

Not sure what you are talking about above. the application as in the
client application connecting to the database or the database
application itself?

Right?

Thanks,

Oleg

On Tue, Jan 5, 2016 at 5:14 PM, Joshua D. Drake <jd@commandprompt.com
<mailto:jd@commandprompt.com>> wrote:

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 pasted, PostgreSQL does fail to a known state.
That is the whole point of the xlog.

Sincerely,

JD

Thanks,

Oleg

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
<tel:503-667-4564>
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

--
Adrian Klaver
adrian.klaver@aklaver.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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 <jd@commandprompt.com>
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 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.

Thanks,

Oleg

On Tue, Jan 5, 2016 at 5:34 PM, Adrian Klaver <adrian.klaver@aklaver.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

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

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 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.

Might want to take a look at:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/postmaster/postmaster.c;h=41dbdf4bf9eeb54ae0a774ab21fc1c1362aa55f9;hb=d25c7d70ff46d1b2f2400f29d100190efe84d70d

/*
* CleanupBackend -- cleanup after terminated backend.
*
* Remove all local state associated with backend.
*
* If you change this, see also CleanupBackgroundWorker.
*/
static void
CleanupBackend

/*
* HandleChildCrash -- cleanup after failed backend, bgwriter, checkpointer,
* walwriter, autovacuum, or background worker.
*
* The objectives here are to clean up our local state about the child
* process, and to signal all other remaining children to quickdie.
*/
static void
HandleChildCrash(in

etc

Just do a find on crash.

Thanks,

Oleg

--
Adrian Klaver
adrian.klaver@aklaver.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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@hogranch.com> wrote:

Hi Joe,

Exactly how I marked it :)

Thanks,

Oleg

On Tue, Jan 5, 2016 at 6:50 PM, Joe Conway <mail@joeconway.com> wrote:

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 <adrian.klaver@aklaver.com>
wrote: