From: Pavlo Golub <pavlo.golub@cybertec.at>
To: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Toshi Harada <harada.toshi@po.ntt-tx.co.jp>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Date: Thu, 6 Jun 2019 13:58:39 +0300
Message-ID: <457444826.20190606135839@cybertec.at> (raw)
In-Reply-To: <31113.1559737923@localhost>
References: <5907.1534140361@localhost>
<201808150211.w7F2ApMj023097@ccmail04.silk.ntt-tx.co.jp>
<19039.1536933944@localhost>
<CA+TgmoawhAmdVaSYt3YLA5dsgoc-oXf72O3ybFAqiARfyTL4iA@mail.gmail.com>
<14646.1552570130@localhost>
<CA+Tgmoawc7hQW2SrcvVSfw8JyYV8UU4fyQ56nxKn_BtPhXfhdQ@mail.gmail.com>
<11812.1554386232@localhost>
<CA+TgmoaAkO0X8t_FeePfv86tysGw2BZivjFv+7=9cKyvVE9M5w@mail.gmail.com>
<7567.1556117300@localhost>
<CA+TgmoaUw3QaHoj_QnkyFVMFLnfsDX32ctOz_zLPReQ-RjAioQ@mail.gmail.com>
<32714.1559057215@localhost>
<CA+TgmoYYrB+WQFVhSqkLmmY7G_wM734BUQ7aA4uMtO4bGFp-mA@mail.gmail.com>
<18987.1559285981@localhost>
<CA+TgmoYs-TPJXdpLpM1qcib-M_CAMO-7wMxBy3yuuMxs8H4L8Q@mail.gmail.com>
<31113.1559737923@localhost>
Greetings, Antonin.
You wrote 2019-06-05, 15:32:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> On Fri, May 31, 2019 at 2:59 AM Antonin Houska <ah@cybertec.at> wrote:
>> > > Sounds good. I'm not quite sure how this is going to work. Ideally
>> > > you'd like the encryption key command to fetch the key from something
>> > > like ssh-agent, or maybe pop up a window on the user's terminal with a
>> > > key prompt. Just reading from stdin and writing to stdout is not
>> > > going to be very convenient...
>> >
>> > When I mentioned writing to stdout in my previous email, I viewed it from the
>> > perspective of postmaster: whichever way the command gets the password from
>> > the DBA, it'll always write it to stdout and postmaster will read it from
>> > there. This was to address your objection that the executables do not actually
>> > "return" strings.
>>
>> So the part about returning strings is really just a wording issue:
>> the documentation needs to talk about data sent to stdout or wherever,
>> because that's what really happens, and somebody writing such a
>> command from scratch needs to know what it must do.
>>
>> What I'm talking about here is that it also has to be reasonably
>> possible to write an encryption key command that does something
>> useful. I don't have a really clear vision for how that's going to
>> work. Nobody wants the server, which is probably being launched by
>> pg_ctl or systemd or both, to prompt using its own stdin/stderr, but
>> the we need to think about how the prompting is actually going to
>> work.
> Since you mentioned ssh-agent above, I think that postmaster can, instead of
> running a command, create an unix socket and read the key from there. (I refer
> only to the socket as a communication channel, not to the protocol - ssh-agent
> does not seem to actually send key over the socket.) Unlike the socket for
> backend connections, this one would only be readable by the user that runs
> postmaster, and would only exist during the encryption initialization.
> The simplest approach from the perspective of the DBA is that pg_ctl can write
> the key to the socket. Besides that we can also implement a separate utility
> to send the key, to be used in other special cases such as starting postgres
> via systemd.
> (If the unix socket is a problem on windows, we might need to use named pipe
> instead.)
Yes, that definitely a problem on Windows. Pipes seems reasonable. Are
mapped files are appropriate from the security point of view?
>> > The header comment in pg_upgrade.c indicates that this is because of TOAST. So
>> > I think that dbnode and relfilenode are not preserved just because there was
>> > no strong reason to do so by now.
>>
>> Maybe you want to propose an independent patch making that change?
> I think of a separate diff in the encryption patch series. As the encryption
> is the only reason for this enhancement, I'm not sure if it deserves a
> separate CF entry. (Although it might be considered refactoring because
> eventually pg_upgrade won't need to handle the different relnodes, and thus it
> might become a little bit simpler.)
--
Kind regards,
Pavlo mailto:pavlo.golub@cybertec.at
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: pavlo.golub@cybertec.at, ah@cybertec.at, robertmhaas@gmail.com, harada.toshi@po.ntt-tx.co.jp
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
In-Reply-To: <457444826.20190606135839@cybertec.at>
* 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