Re: For review: Server instrumentation patch

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>It could be argued that there should be provision for a limitation on
>>the locations in which COPY can write (and maybe read) files.
>>If COPY is a security hole then we should close it, not use that as
>>precedent to open another hole.
>>
>>
>
>Yeah. It's worth pointing out in this connection that server-side
>COPY is already pretty well crippled if you are running under SELinux,
>because the security policy constrains what parts of the filesystem
>the daemon can reach at all. I've already been thinking seriously
>of proposing that the regression tests be converted to use only
>\copy and not COPY, because it's difficult to run them against an
>installed server on Fedora 4, and it may be impossible in the near
>future.
>
>
>
>

That also occurred to me. I have taken to turning off SELinux altogether
but some day I'm going to have to stop that.

How about if we do something like this?:

. initdb creates a tmpdir inside the datadir
. a new GUC var called allowed_copy_locations which is a PATH type
string specifying what directories we can copy to/from. This would by
default be "$tmpdir"
. in addition to an absolute path, a copy path could begin with $tmpdir
. explicitly setting the GUC to "*" would allow any absolute location as
now (having this not the default means admins would have to turn it on
deliberately, which would be a Good Thing (tm)).

possible extra:
. another GUC var to specify an alternative location for $tmpdir.

cheers

andrew