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.eisentr...@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 > >