Re: Permissions

On Tue, Sep 20, 2016 at 11:17:47PM +0200, Andre Labuschagne wrote:
>
> > 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.

Andre,

There are plenty of non-Postgres solutions to the problem, such as hardware
or volume encryption of the storage devices. If you're worried about
security of your backups, then it's the job of your backup solution to
encrypt the backups, not Postgres.

Why should Postgres make a specific implementation of something that is
generally available?

--
-- Skylar Thompson (skylar2(at)u(dot)washington(dot)edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine