From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
cc: Stephen Frost <sfrost@snowman.net>,
    PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Temporary file access API
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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
   message dated "Mon, 11 Apr 2022 16:34:18 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3689.1649755839.1@antos>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Apr 2022 11:30:39 +0200
Message-ID: <3690.1649755839@antos>
Archived-At: <https://www.postgresql.org/message-id/3690.1649755839%40antos>
Precedence: bulk

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_t=
he_files_that_contain_user_data
> >
> > (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 fi=
les:

https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommit;h=3D5891c=
7a8ed8f2d3d577e7eea34dacff12d7b6bbd

> 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