From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql(at)mohawksoft(dot)com |
Cc: | "John Hansen" <john(at)geeknet(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Configure redux. |
Date: | 2004-05-12 12:35:48 |
Message-ID: | 23840.1084365348@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
pgsql(at)mohawksoft(dot)com writes:
> They say the absolute path is a security issue, I honestly don't see how
Because it allows someone with only CREATEDB privilege to tell the
backend to write anywhere (that it can write). That's an ability
that should be reserved to superusers.
The environment-variable-based variant is actually not a lot better.
Consider CREATEDB WITH LOCATION 'HOME'. Or 'PWD'. Depending on your
platform, "env | grep =/" may reveal other interesting possibilities.
The problem is that a postmaster's environment will contain a lot of
strings that happen to look like absolute paths. There is no way for
the code to know which ones were really intended by the DBA to be used
as locations, and which ones are just part of the standard environment
on a particular platform.
Either way you slice it, WITH LOCATION is fundamentally bogus because it
allows users to create databases in unintended locations. I don't think
it can be used to overwrite existing files, so it's not a security hole
in the sense of allowing attacks, but it is a security hole in the sense
of not giving the DBA a reliable way to control database locations.
I have every intention of ripping that code out, root and branch, as
soon as we have a real tablespace feature (which I'm expecting will
provide means within the system for defining allowed physical
locations). I don't recommend spending any time on improving the
feature, because its days are numbered.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-12 12:47:09 | Re: Module dependency on PostgeSQL version |
Previous Message | Oleg Bartunov | 2004-05-12 12:14:09 | Re: Subtle pg_dump problem... |