On Mon, Jul 8, 2019 at 12:09:58PM -0400, Joe Conway wrote:
> On 7/8/19 11:56 AM, Peter Eisentraut wrote:
> > On 2019-07-08 17:47, Stephen Frost wrote:
> >> Of course, we can discuss if what websites do with over-the-wire
> >> encryption is sensible to compare to what we want to do in PG for
> >> data-at-rest, but then we shouldn't be talking about what websites do,
> >> it'd make more sense to look at other data-at-rest encryption systems
> >> and consider what they're doing.
> >
> > So, how do encrypted file systems do it? Are there any encrypted file
> > systems in general use that allow encrypting only some files or
> > encrypting different parts of the file system with different keys, or
> > any of those other granular approaches being discussed?
>
> Well it is fairly common, for good reason IMHO, to encrypt some mount
> points and not others on a system. In my mind, and in practice to a
> large extent, a postgres tablespace == a unique mount point.
Yes, that is a normal partition point for key use because one file
system is independent of others. You could use different keys for
different directories in the same file system, but internally it all
uses the same storage, and storage theft would potentially happen at the
file system level.
For Postgres, tablespaces are not independent of the database system,
though media theft would still match. Of course, in the case of a
tablespace media theft, Postgres would be quite confused, though you
could still start the database system:
SELECT * FROM test;
ERROR: could not open file
"pg_tblspc/16385/PG_13_201907054/16384/16386": No such file or directory
but the data would be gone. What you can't do with Postgres is to have
the tablespace be inaccessible and then later reappear.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
