Re: Permissions - Mailing list pgsql-novice

> On 20 Sep 2016, at 23:23, Skylar Thompson <skylar2@u.washington.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.g.johnston@gmail.com> wrote:
>>>
>>> On Tue, Sep 20, 2016 at 1:53 PM, Andre Labuschagne <technical@eduadmin.com <mailto:technical@eduadmin.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
generallyconsidered "data at rest".???  Data in transit is stuff flowing on the wires when you, e.g., connect psql to
thedatabase and makes queries.  The server is capable of leveraging SSL to setup secure tunnels for data in transit.
Theserver does not itself encrypt data at rest whether it is the data files, WAL, or in-memory data buffers.
Supplementaloptions 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
restrictaccess 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@u.washington.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
installationsto be able to create their own databases and some of them we supply from head office.  The ones we supply
applicationswill be using.  When the on site administrators use something like pgAdmin they must not be able to tamper
withthe databases that we have supplied - no backing up or accessing and so on.  Both Sybase and Mimer allow this as
explicitlogin 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
obviousway 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