Re: For review: Server instrumentation patch

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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?

I'm not exactly convinced this *actually* provides superusers any more
permissions than they already have. As someone else has pointed out,
there's COPY, and I'd think the whole can-dynamically-load-.so's would
trump any claims that you can give someone remote postgres superuser
'safely' (ie: and think it prevents them from being able to do things as
the postgres account on the system).

Indeed, I'd tend to think that's just about *exactly* what giving
someone postgres superuser access means- full access to the system as
that unix account.

> 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.

Those admins should probably be educated that giving someone postgres
superuser is pretty much giving them local access as the user postgres
runs as. I don't believe it'd be appropriate to try and claim anything
else...

> 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.

Given the somewhat lacking use-case (Working through postgres isn't
exactly the way *I'd* tend to mess with the filesystem directly, so this
seems like a pretty poor use-case to me) I'd agree that it'd be more
appropriate as a contrib module, but let's not confuse that with
security concerns.

> 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.

I doubt this as I expect security-conscious admins will understand what
being able to dynamically load a .so means, and will be aware of such
things as COPY. As such, I'd tend to think security-conscious admins
would deny remote superuser access anyway...

Stephen