Re: Permissions

> On 20 Sep 2016, at 23:23, Skylar Thompson <skylar2(at)u(dot)washington(dot)edu> wrote:
>
> 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
>
>

Hi Skylar

We are talking about thousands of installations within the organisation. Ideally we need to allow the users at the installations to be able to create their own databases and some of them we supply from head office. The ones we supply applications will be using. When the on site administrators use something like pgAdmin they must not be able to tamper with the databases that we have supplied - no backing up or accessing and so on. Both Sybase and Mimer allow this as explicit login and password is required to each database, even if you are a super user. It is not just about backing up - it is the entire gambit. I was just trying to redirect the discussion when I referred to backing up as that is the obvious way for a rogue employee to make a copy of that data or stop the database and copy it manually.

Hope that makes sense.

Cheers
Andre