Re: [PATCHES] Configuration patch
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] Configuration patch |
Дата | |
Msg-id | 200406111822.i5BIMGU24265@candle.pha.pa.us обсуждение исходный текст |
Ответы |
Re: [PATCHES] Configuration patch
|
Список | pgsql-hackers |
Where are we on this? --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > One interesting idea would be for "SET include" to work like this: > > SET include '/var/run/xx' > > Notice there is no equals here. This would allow users to create files > > with various settings and enable them all with one SET command. > > However, this does open a security issue. > > More than one, in fact. In the first place, as the code presently > works, anything coming in from the file would be treated on an equal > footing with values sourced from postgresql.conf, thereby allowing > unprivileged users to set things they shouldn't. This is potentially > fixable, but the other issue isn't: such a facility would allow anyone > to ask the backend to read any file the Postgres user account can > access. Not very successfully, perhaps, but even the error messages > might give useful info about the file's contents to an attacker. This > is the same reason that "COPY FROM file" is a privileged operation. > > I think it's important that include be restricted to appear only in > config files, and not be in any way shape or form a SETtable thing. > > > In summary, I think we need to treat include specially in > > postgresql.conf (no equals) and remove it as an actual GUC parameter and > > just have it do includes immediately. (This will probably require > > special-casing it in the guc-file grammar.) > > Yes. In fact, it'll be a less-than-trivial change in guc-file, at least > if you want the thing to act intuitively (that is, "include" acts like > the target file is actually included right here). This will mean > splitting ProcessConfigFile into a recursive read step followed by a > nonrecursive apply step. Also, I think that invoking the flex lexer > recursively will take a little bit of work. > > I would suggest splitting the patch into two separate patches, one that > handles "include" and one that handles the other changes. The other > stuff is reasonably close to being ready to apply (modulo docs and > fixing the standalone-backend case), but "include" I think is still a > ways off. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: