| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Andre Labuschagne <technical(at)eduadmin(dot)com> |
| Cc: | Alan Hodgson <ahodgson(at)lists(dot)simkin(dot)ca>, "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
| Subject: | Re: Permissions |
| Date: | 2016-09-20 23:09:57 |
| Message-ID: | CAKFQuwaGnWx6RW89kVxpKXtfYD90iCnaL5nKiUs4Yz_hjLQkuA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
On Tue, Sep 20, 2016 at 3:09 PM, Andre Labuschagne <technical(at)eduadmin(dot)com>
wrote:
> All permissions ship with the database. It works quite brilliantly as the
> only access to the databases shipped is through the apps that ship and no
> tool will allow tampering with the objects that have been explicitly
> granted to specific users by the owners of the objects. It works very well.
>
PostgreSQL has an entirely different architecture that is not particularly
amenable to what you describe.
If the remote site admins have admin/root access on the machine hosting
the PostgreSQL database you cannot prevent them from doing anything they
want to the database. You might be able to compile a pre-shared key into
the application and encrypt all data at rest. That is what these other
tools would have to be doing otherwise your perception of encryption is
broken since the admin could simply read the bytes off the disk and
decompress/decode them into text (presuming said algorithm is
discover-able).
As for the "trust tool"...just read the docs on pb_hba.conf
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | amul sul | 2016-09-21 09:10:29 | Re: SELECT FOR UPDATE returns zero rows |
| Previous Message | Andre Labuschagne | 2016-09-20 22:09:36 | Re: Permissions |