On Wed, Nov 13, 2019 at 01:20:43PM +0000, Simon Riggs wrote:
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian <br...@momjian.us> wrote:
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian <br...@momjian.us> wrote:
> > One of the main reasons there being to be easily able to transfer more
state
> > and give results other than just an exit code, no need to deal with
parameter
> > escaping etc. Which probably wouldn't matter as much to an SSL
passphrase
> > command, but still.
>
> I get the callback-is-easier issue with shared objects, but are we
> expecting to pass in more information here than we do for
> archive_command? I would think not. What I am saying is that if we
> don't think passing things in works, we should fix all these external
> commands, or something. I don't see why ssl_passphrase_command is
> different, except that it is new.
Or is it related to _securely_passing something?
Yes
I think it would be beneficial to explain why shared object is more
secure than an OS command. Perhaps it's common knowledge, but it's not
quite obvious to me.
> Also, why was this patch posted without any discussion of these issues?
> Shouldn't we ideally discuss the API first?
I wonder if every GUC that takes an OS command should allow a shared
object to be specified --- maybe control that if the command string
starts with a # or something.
Very good idea
If it's about securely passing sensitive information (i.e. passphrase)
as was suggested, then I think that only applies to fairly small number
of GUCs.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
