Dear Hackers.
Thank you for an response.
I registered this entry in commifest of 2020-03.
# I registered in the security part, but if it is wrong, sincerely
apologize for this.
And I'd like to review show authority to ssl_ * later and discuss it
in a separate thread.
Best regards.
Moon.
On Thu, Feb 13, 2020 at 6:11 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-02-13 04:38, Michael Paquier wrote:
> > On Thu, Feb 13, 2020 at 11:28:05AM +0900, Kyotaro Horiguchi wrote:
> >> I think it is reasonable.
> >
> > Indeed, that makes sense to me as well. I am adding Peter Eisentraut
> > in CC as the author/committer of 8a3d942 to comment on that.
>
> I'm OK with changing that.
>
> >> By the way, I'm not sure the criteria of setting a GUC variable as
> >> GUC_SUPERUSER_ONLY, but for example, ssl_max/min_protocol_version,
> >> dynamic_library_path, log_directory, krb_server_keyfile,
> >> data_directory and config_file are GUC_SUPERUSER_ONLY. So, it seems to
> >> me very strange that ssl_*_file are not. Don't we need to mark them
> >> maybe and some of the other ssl_* as the same?
> >
> > This should be a separate discussion IMO. Perhaps there is a point in
> > softening or hardening some of them.
>
> I think some of this makes sense, and we should have a discussion about it.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
