On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
On 11/14/19 11:07 AM, Bruce Momjian wrote:
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <tomas.von...@2ndquadrant.com>
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.
Yeah, that probably wouldn't hurt. It's also securely passing from more than
one perspective -- both from the "cannot be eavesdropped" (like putting the
password on the commandline for example) and the requirement for escaping.
I think a bigger issue is that if you want to give people the option of
using a shell command or a shared object, and if you use two commands to
control it, it isn't clear what happens if both are defined. By using
some character prefix to control if a shared object is used, you can use
a single variable and there is no confusion over having two variables
and their conflicting behavior.
I'm not sure how that would work in the present instance. The shared
preloaded module installs a function and defines the params it wants. If
we somehow unify the params with ssl_passphrase_command that could look
icky, and the module would have to parse the settings string. That's not
a problem for the sample module which only needs one param, but it will
be for other more complex implementations.
I'm quite open to suggestions, but I want things to be tolerably clean.
I agree it's better to have two separate GUCs - one for command, one for
shared object, and documented order of precedence. I suppose we may log
a warning when both are specified, or perhaps "reset" the value with
lower order of precedence.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
