Re: Temporary file access API - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Temporary file access API
Date
Msg-id CA+TgmoaJ74opLkguCmm+Du9T1mAPtPYThCQhF_bbhZW5i4VAkg@mail.gmail.com
Whole thread Raw
In response to Re: Temporary file access API  (Antonin Houska <ah@cybertec.at>)
Responses Re: Temporary file access API
Re: Temporary file access API
List pgsql-hackers
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_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.
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?

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

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: How about a psql backslash command to show GUCs?
Next
From: Robert Haas
Date:
Subject: Re: make MaxBackends available in _PG_init