Notes on config-file-locations patch
От | Tom Lane |
---|---|
Тема | Notes on config-file-locations patch |
Дата | |
Msg-id | 28346.1097339664@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Notes on config-file-locations patch
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-hackers |
There are some loose ends and inconsistencies left in the config-file- locations feature, which I'm planning to clean up. One problem is that although the GUC variables allow you to find out the location of the secondary config files, you can't verify which main config file (postgresql.conf) the postmaster is using. Another is that the behavior when you write a relative path instead of an absolute path for one of these variables is undocumented and not very consistent. Also, I've concluded that it's bizarre and confusing to allow the postmaster's -D switch to reference either a directory or a config file. What I propose to do about this is to invent an additional GUC variable "config_file" (any suggestions for a better name?) that can be used on the postmaster command line to select the main config file. (Obviously it can't be set in the config file itself, so the command line is the only useful place to set it.) The rules would go like this: 1. If -D appears on the command line, its argument is the "configuration directory"; otherwise if PGDATA is set in the environment, its value is the configuration directory; otherwise the configuration directory is undefined. 2. If "-c config_file=foo" appears on the command line, that's where the main config file is. Otherwise a configuration directory must be defined, and the main config file is ConfDir/postgresql.conf. 3. Read the config file. 4. If the "pgdata" GUC variable has been set, either in the config file or on the command line, that's where the data directory is. Otherwise a configuration directory must be defined, and it also becomes the data directory. 5. If the "hba_file" GUC variable has been set, either in the config file or on the command line, that's where the pg_hba.conf file is. Otherwise a configuration directory must be defined, and the HBA config file is ConfDir/pg_hba.conf. Similarly for the IDENT config file, and any others we might invent in future. 6. If any of the paths obtained by these rules are relative, they are converted to absolute relative to the postmaster's startup directory. 7. By the end of postmaster startup, the GUC variables pgdata, config_file, hba_file, etc are filled with the correct absolute paths for the data directory and config files, whether they were explicitly specified or not. These variables cannot be changed after startup, but they can be inspected to verify which postmaster one is really connected to. The main difference between this and the CVS-tip behavior is that if you want to specify the main config file directly, you write --config_file instead of -D. I think that's less confusing than overloading -D with multiple meanings. It wasn't clear to me whether we had a consensus to prevent non-superusers from reading the values of these GUC variables. I'm still inclined to do that, but I'll hold off until the discussion is done. regards, tom lane
В списке pgsql-hackers по дате отправления:
Следующее
От: Peter EisentrautДата:
Сообщение: Re: Security implications of config-file-location patch