Andrew Sullivan <andrew@libertyrms.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.
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.
A mechanism based only on a fixed environment variable name doesn't
create the sort of threat I'm contemplating. For example, if the
postmaster always and only looked at $PGXLOG to find the xlog then
you'd not have this type of risk. But Thomas said he was basing the
feature on database locations, and in the absence of seeing the code
I don't know if he's creating a security hole or not.
regards, tom lane
