Re: Permissions - Mailing list pgsql-novice

From David G. Johnston
Subject Re: Permissions
Date
Msg-id CAKFQuwbNvJHW_5Cq+nQaUkqrB642bJeywm27KWppk6=ZUa6XLA@mail.gmail.com
Whole thread Raw
In response to Re: Permissions  (Andre Labuschagne <technical@eduadmin.com>)
Responses Re: Permissions  (Andre Labuschagne <technical@eduadmin.com>)
List pgsql-novice
On Tue, Sep 20, 2016 at 2:17 PM, Andre Labuschagne <technical@eduadmin.com> wrote:

Hi David

Our usage of the terms is the exact opposite.

I am simply referring to the database being taken else mounted and accused.  We can refer to that as at rest.  If we restrict access when it has “left” the initial PG server and mounted onto another PG server then we have a solution.   But your reference to the little tool that enables trust seems to blow all security out of the water.  It is troublesome.


​There are many external tools that will encrypt files.  You can also setup a filesystem that has encryption features.​  You don't necessarily need the full cooperation of PostgreSQL to make things meet your definition/trade-off of secure.

IMHO, The "little tool that enables trust" really isn't a problem by itself (and its not really a tool...) but rather has a slight impact of the potential risk surface and learning curve.  It probably shouldn't be used in production but can come in handy in other setups.  You've already lost once some gets a hold of unencrytped data files - a problem that can be readily solved outside of PostgreSQL - that its a bit easier to spin up the database and access the database is just opening the barn door a bit further.

There are many others on these lists, and in the community, more knowledgeable in security than I.  It can be made considerably more secure than it comes "out of the box".

David J.

pgsql-novice by date:

Previous
From: Skylar Thompson
Date:
Subject: Re: Permissions
Next
From: Andre Labuschagne
Date:
Subject: Re: Permissions