Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Configuration patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql(at)mohawksoft(dot)com,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Configuration patch
Date: 2004-06-03 22:03:53
Message-ID: 11364.1086300233@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-06-03 22:41:24
Subject: Re: [HACKERS] Configuration patch
Previous:From: Joshua D. DrakeDate: 2004-06-03 22:01:41
Subject: Re: [HACKERS] Not 7.5, but 8.0 ?

pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-06-03 22:41:24
Subject: Re: [HACKERS] Configuration patch
Previous:From: Bruce MomjianDate: 2004-06-03 21:45:34
Subject: Re: [HACKERS] Configuration patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group