Andreas Pflug <pgadmin@pse-consulting.de> writes:
>> This patch looks good. The only question I have is why you
>> didn't want the pgport rename/unlink calls?
> Because I wanted the standard platform behaviour of both. For backend
> storage subsystem purposes, it's certainly necessary to emulate *ix
> behaviour of deleting a file in use, but for generic file access IMHO
> the generic behaviour should be exposed.
I'm going to repeat my firm opposition to this patch. Under the
innocuous-sounding banner of "server instrumentation", you are once
again trying to put in generic file access capabilities that will allow
remote Postgres superusers full access to the server filesystem.
The potential security risks of this are obvious to anyone. The only
justification that has been offered is "this will make remote
administration easier". Well, yeah, but it will make remote breakins
easier too. Valuing ease of use over security is the philosophy that
got Microsoft into the mess they're in now --- do we want to follow
that precedent?
The use-case for this seems to be to substitute for having local login
privileges on the server machine. Well, if the sysadmins of that
machine refuse to give you manual login privileges, they probably have
good reasons for it, and will not be very happy to see an end-run around
their restriction in the form of the database giving you remote
filesystem access.
I would have no problem with this patch as an optional add-on (eg, a
contrib module), so that individual installations could decide whether
they want to take the incremental security risk. In that form it's
basically equivalent to deciding you want to install an untrusted
PL language. We don't install those by default and we shouldn't install
generic filesystem access by default either.
If we accept this patch I foresee security-conscious admins starting to
question whether they should allow Postgres to be installed at all on
their systems. We don't need that kind of impediment to acceptance.
regards, tom lane
