Re: WAL file location - Mailing list pgsql-hackers

> The trouble with relying on environment variables for paths (especially
> paths to places that we might scribble on) is that the postmaster has
> no idea which strings in its environment were actually intended for that
> use, and which were not.

True, in the simplest implementation (Peter E. has suggested extensions
to address this complaint). But not relevant to security under likely
scenarios. See below.

> As an example, the postmaster very likely has $HOME in its environment.
> This means that anyone with createdb privilege can try to create a
> database in the postgres user's home directory.  It's relatively
> harmless (since what will actually get mkdir'd is some name like
> /home/postgres/base/173918, which likely can't overwrite anything
> interesting) but it's still not a good idea.

Actually, this can not happen! You will see that the combination of
initlocation, environment variables, and other backend requirements will
force this kind of exploit to fail, since PostgreSQL requires a
structure of directories (like $PGDATA/data/base) but the environment
variable is only allowed to prepend the "data/base/oid" part of the
path.

So the directory *must* be set up properly beforehand, and must have the
correct structure, greatly reducing if not eliminating possible
exploits.

This is *not* possible in any scenerio for which the postmaster or a
server instance or a client connection has full control over the
attributes and definitions of data storage areas. Decoupling them
(requiring two distinct orthogonal mechanisms) is what enhances security
and data integrity. None of the "I hate environment variables"
discussions have addressed this issue.

> $PWD would be another likely attack point, and possibly one could do
> something with $PATH, not to mention any custom environment variables
> that might happen to exist in the local environment.

Again, not likely possible. See above.

> 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.

No. See above.

> > In any case, it'd be a _very good_ thing to have a tablespace-like
> > facility.
> Absolutely.  But let's not drive it off environment variables.
> A config file is far safer.

Disagree, but in a friendly sort of way ;) I will likely implement both,
if either. Along the way I will give some specific use cases so we don't
go 'round on this topic every time...
                 - Thomas