Re: Expand the use of check_canonical_path() for more GUCs
От | Mark Dilger |
---|---|
Тема | Re: Expand the use of check_canonical_path() for more GUCs |
Дата | |
Msg-id | FCADDFF2-CA5B-49CD-A3C3-A3FA1F226DC9@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Expand the use of check_canonical_path() for more GUCs (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Expand the use of check_canonical_path() for more GUCs
|
Список | pgsql-hackers |
> On May 20, 2020, at 12:03 AM, Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, May 19, 2020 at 09:32:15AM -0400, Tom Lane wrote: >> Hm, I'm pretty certain that data_directory does not need this because >> canonicalization is done elsewhere; the most that you could accomplish >> there is to cause problems. Dunno about the rest. > > Hmm. I missed that this is getting done in SelectConfigFiles() first > by the postmaster so that's not necessary, which also does the work > for hba_file and ident_file. config_file does not need that either as > AbsoluteConfigLocation() does the same work via ParseConfigFile(). So > perhaps we could add a comment or such about that? Attached is an > idea. > > The rest is made of PromoteTriggerFile, pg_krb_server_keyfile, > ssl_cert_file, ssl_key_file, ssl_ca_file, ssl_crl_file and > ssl_dh_params_file where loaded values are taken as-is, so applying > canonicalization would be helpful there, no? Before this patch, there are three GUCs that get check_canonical_path treatment: log_directory external_pid_file stats_temp_directory After the patch, these also get the treatment (though Peter seems to be objecting to the change): promote_trigger_file krb_server_keyfile ssl_cert_file ssl_key_file ssl_ca_file ssl_crl_file ssl_dh_params_file and these still don't, with comments about how they are already canonicalized when the config file is loaded: data_directory config_file hba_file ident_file A little poking around shows that in SelectConfigFiles(), these four directories were set by SetConfigOption(). I don'tsee a problem with the code, but the way this stuff is spread around makes it easy for somebody adding a new GUC filepath to do it wrong. I don't have much opinion about Peter's preference that paths be left alone, but I'd prefer somecomments in guc.c explaining it all. The only cleanup that occurs to me is to reorder ConfigureNamesString[] to haveall the path options back-to-back, with the four that are set by SelectConfigFiles() at the top with comments about whythey are special, and the rest after that with comments about why they need or do not need canonicalization. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: