Re: [PATCHES] Configuration patch

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql(at)mohawksoft(dot)com, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] Configuration patch
Date: 2004-06-11 18:22:16
Message-ID: 200406111822.i5BIMGU24265@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Where are we on this?

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-06-11 18:25:03 Re: [PATCHES] serverlog function (log_destination file)
Previous Message Tom Lane 2004-06-11 18:20:26 Re: [PATCHES] serverlog function (log_destination file)

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-06-11 18:25:03 Re: [PATCHES] serverlog function (log_destination file)
Previous Message Tom Lane 2004-06-11 18:20:26 Re: [PATCHES] serverlog function (log_destination file)