Re: WAL file location

From: Curt Sampson <cjs(at)cynic(dot)net>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Thomas Lockhart <lockhart(at)fourpalms(dot)org>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL file location
Date: 2002-07-30 23:21:09
Message-ID: Pine.NEB.4.44.0207310758010.454-100000@angelic.cynic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 30 Jul 2002, Lamar Owen wrote:

> Now, let me make the statement that the environment in this case is
> not likely to be a security issue any worse than having the stuff
> in postgresql.conf, as any attacker that can poison the postmaster
> environment can probably poison postgresql.conf.

Unfortunately, the environment is already "pre-poisoned." Typically the
environment is full of variables that have nothing to do with postgres
but which have paths pointing to various places. This is the sort of
thing that might allow you to exploit an otherwise unexploitable bug in
postgres.

Potgres not being able to use any of that information would be one layer
of security. You might argue that it's not a big one, but it's often just
dumb little things like this that give you remote exploits.

> Since postmaster doesn't run as root, it can't be used to overwrite
> system files, the typcial target for environment poisoning.

So? It can still be used to read some files on the system, which
might provide useful information to an attacker. And future additions
to postgres might change the situation. Say, for example, that someone
added the ability to store data on raw devices. Now you have to worry
that someone might be able to get postgres to write rubbish to some
raw devices it has access to if an environment variable has /dev in it.

Simplicty is always a big help to security. Rather than spending time
doing a big, complex analysis of just why we think using the environment
variables are safe, it's much simpler just not to use them. And if
we re-used existing configuration file processing code to get the
information we need, we'd also be removing some code from the system,
thus removing the potential for bugs in that code.

The discussion in the archives seems quite positive about the patch,
except for one or two recalcitrant people that disagree with everyone
else. And in the very first post I found, Tom Lane said:

This whole thread makes me more and more uncomfortable about the
fact that the postmaster/backend pay attention to environment
variables at all. An explicit configuration file would seem a better
answer.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-07-30 23:28:29 Re: ROW features
Previous Message Tom Lane 2002-07-30 22:51:07 Re: DROP COLUMN round 4