Re: Internal key management system
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
Fabien COELHO <coelho@cri.ensmp.fr>,
Cary Huang <cary.huang@highgo.ca>,
Ahsan Hadi <ahsan.hadi@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
"Moon,
Insung" <tsukiwamoon.pgsql@gmail.com>,
Robert Haas <robertmhaas@gmail.com>,
Sehrope Sarkuni <sehrope@jackdb.com>, cary huang <hcary328@gmail.com>,
Ibrar Ahmed <ibrar.ahmad@gmail.com>, Joe Conway <mail@joeconway.com>
Date: 2020-10-16T20:56:47Z
Lists: pgsql-hackers
Bruce Momjian <bruce@momjian.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. regards, tom lane [1] https://www.postgresql.org/message-id/flat/CAEET0ZH5Bf7dhZB3mYy8zZQttJrdZg_0Wwaj0o1PuuBny1JkEw%40mail.gmail.com