Re: [PATCHES] Configuration patch

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PATCHES] Configuration patch
Дата
Msg-id 200406111822.i5BIMGU24265@candle.pha.pa.us
обсуждение исходный текст
Ответы Re: [PATCHES] Configuration patch  (pgsql@mohawksoft.com)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] serverlog function (log_destination file)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] serverlog function (log_destination file)