Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Andreas didn't ask for a full file API. I suggested it because we were
> already going to have some of the functionality. If rename/unlink are
> new problems, we can skip them and just add what Andreas needs right
> now.
Given the security worries that have been raised, and the fact that none
of this functionality existed in the patch as it stood at feature-freeze
time, I think there's more than sufficient reason to defer all the
writing stuff to a future release cycle.
I'd like to limit the functionality added now to just file-read and
directory-list commands; and perhaps we ought to go back to limiting
them to work on the configured log output directory rather than being
general purpose. If they are general purpose, I'm going to want them to
take only absolute paths, which will make it harder to use them for
fetching the logs. (Not impossible, since we could demand that the GUC
variable holding the log directory be an absolute path, but maybe it's
just better to stay away from the notion of a general file access API
until we've thought harder about the security implications.)
regards, tom lane
