> pgsql@mohawksoft.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.
I guess I can see that.
>
> 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.
Well, is there a doc on how tables spaces will be implemented?
Do you intend to have postmaster initialize the tablespace, or will the
admin be required to perform an initlocation?
I already have a keyword in my config patch called 'volume' but
'tablespace' would probably be a better name for it. A simple name change
would work.
