Re: Permissions

From: Andre Labuschagne <technical(at)eduadmin(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Permissions
Date: 2016-09-20 21:17:47
Message-ID: 648FC074-DA96-41B3-B4CF-509848C5AF98@eduadmin.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice


> On 20 Sep 2016, at 23:03, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Tue, Sep 20, 2016 at 1:53 PM, Andre Labuschagne <technical(at)eduadmin(dot)com <mailto:technical(at)eduadmin(dot)com>> wrote:
> Thanks for that. So PG de facto has absolutely no security while in transit then. That is what we are trying to establish.
>
> ​Your definition of "in transit" is unusual...someone obtaining a copy of a backup (or any data files) is generally considered "data at rest".​ Data in transit is stuff flowing on the wires when you, e.g., connect psql to the database and makes queries. The server is capable of leveraging SSL to setup secure tunnels for data in transit. The server does not itself encrypt data at rest whether it is the data files, WAL, or in-memory data buffers. Supplemental options in this area are present but I am unfamiliar with them.
>
> David J.
>

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.

Cheers
Andre

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Skylar Thompson 2016-09-20 21:23:12 Re: Permissions
Previous Message David G. Johnston 2016-09-20 21:03:06 Re: Permissions