pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Temporary file access API
Date: Tue, 12 Apr 2022 11:30:39 +0200
Message-ID: <3690.1649755839@antos> (raw)
In-Reply-To: <CA+TgmoaJ74opLkguCmm+Du9T1mAPtPYThCQhF_bbhZW5i4VAkg@mail.gmail.com>
References: <4987.1644323098@antos>
	<20220301143431.GT10577@tamriel.snowman.net>
	<27013.1646738099@antos>
	<CA+TgmobnojZw6mZi0T_61RtUDgsxroYhp+DJU5Yhz6caxUrQgw@mail.gmail.com>
	<3146.1649408068@antos>
	<CA+TgmobQM4Yym3944tFpcaJX4EfYs92Vv4NCY3V0R5BE4RU2rg@mail.gmail.com>
	<2132.1649664364@antos>
	<CA+TgmoaJ74opLkguCmm+Du9T1mAPtPYThCQhF_bbhZW5i4VAkg@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> wrote:

> On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska <ah@cybertec.at> wrote:
> > There are't really that many kinds of files to encrypt:
> >
> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_dat...
> >
> > (And pg_stat/* files should be removed from the list.)
> 
> This kind of gets into some theoretical questions. Like, do we think
> that it's an information leak if people can look at how many
> transactions are committing and aborting in pg_xact_status? In theory
> it could be, but I know it's been argued that that's too much of a
> side channel. I'm not sure I believe that, but it's arguable.

I was referring to the fact that the statistics are no longer stored in files:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5891c7a8ed8f2d3d577e7eea34dacff12d7b6...

> Similarly, the argument that global/pg_internal.init doesn't contain
> user data relies on the theory that the only table data that will make
> its way into the file is for system catalogs. I guess that's not user
> data *exactly* but ... are we sure that's how we want to roll here?

Yes, this is worth attention.

> I really don't know how you can argue that pg_dynshmem/mmap.NNNNNNN
> doesn't contain user data - surely it can.

Good point. Since postgres does not control writing into this file, it's a
special case though. (Maybe TDE will have to reject to start if
dynamic_shared_memory_type is set to mmap and the instance is encrypted.)

Thanks.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com





view thread (30+ messages)  latest in thread

Message-ID: <3690.1649755839@antos>
Permalink:  ../3690.1649755839@antos/
Also on:    postgresql.org/message-id/3690.1649755839@antos

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: ah@cybertec.at, robertmhaas@gmail.com, sfrost@snowman.net, pgsql-hackers@lists.postgresql.org
  Subject: Re: Temporary file access API
  In-Reply-To: <3690.1649755839@antos>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox