Re: Internal key management system

On Fri, Oct 16, 2020 at 04:56:47PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Second, in testing starting/stopping the server, pg_ctl doesn't allow
> > the cluster_passphrase_command to read from /dev/tty, which I think is a
> > requirement because the command could likely require a user-supplied
> > unlock key, even if that is not the actual passphrase, just like ssl
> > keys. This is because pg_ctl calls setsid() just before calling execl()
> > to start the server, and setsid() disassociates itself from the
> > controlling terminal. I think the fix is to remove setsid() from pg_ctl
> > and add a postmaster flag to call setsid() after it has potentially
> > called cluster_passphrase_command, and pg_ctl would use that flag.
>
> We discussed that and rejected it in the thread leading up to
> bb24439ce [1]. The primary problem being that it's not very clear
> when the postmaster should daemonize itself, and later generally
> isn't better. I doubt that this proposal is doing anything to
> clarify that situation.

Agreed. No reason to destablize the postmaster for this. What about
having pg_ctl open /dev/tty, and then pass in an open file descriptor
that is a copy of /dev/tty, that can be closed by the postmaster after
the cluster_passphrase_command? I just tested this and it worked.

I am thinking we would pass the file descriptor number to the postmaster
via a command-line argument. Ideally we would pass in the device name
of /dev/tty, but I don't know of a good way to do that.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee