* Tom Lane ([EMAIL PROTECTED]) 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
signature.asc
Description: Digital signature
