Re: WAL file location

On Tuesday 30 July 2002 02:34 pm, Tom Lane wrote:
> Andrew Sullivan <andrew(at)libertyrms(dot)info> writes:
> > On Tue, Jul 30, 2002 at 02:05:57PM -0400, Tom Lane wrote:
> >> If we add more environment-variable-dependent mechanisms to allow more
> >> different things to be done, we increase substantially the odds of
> >> creating an exploitable security hole.

> > Ok, true enough, but I'm not sure that a config file or any other
> > such mechanism is any safer. As Lamar Owen said, anyone who can
> > poison the postgres user's environment can likely do evil things to
> > postgresql.conf as well.

> Who said anything about poisoning the environment? My point was that
> there will be strings in the environment that were put there perfectly
> legitimately, but could still serve as an attack vehicle.

I said it. In any case, using strings that are in the environment requires an
untrusted PL, or a C function. Regardless, if such a hole was exploited the
only security risk to the system at large is that posed by the postgres user,
which, IMHO, shouldn't even have write access to its own executables. And if
someone can exploit the environment in that way, with a server-side function,
then that same person will be able to execute arbitrary code as the
postmaster run user anyway, without any environment variables being accessed.
Unless environment access is allowed in trusted functions....

Although that is one reason the HOME for the RPMset is /var/lib/pgsql, a place
postgres has free rein anyway.

> The weakness of the existing database-locations-are-environment-variables
> feature is really that the attacker gets to choose which environment
> variable gets used, and so he can use a variable intended to serve
> purpose A for some other purpose B. If A and B are sufficiently
> different then you got trouble --- and since we are talking about a
> purpose B that involves writing on something, there's definitely a risk.

To data already owned by postgres only. I wouldn't mind seeing an example of
such an exploit, for educational purposes.

Having said all that, I still believe that this is something tailor-made for
postgresql.conf.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11