From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: For review: Server instrumentation patch |
Date: | 2005-07-24 20:33:17 |
Message-ID: | 20050724203317.GY24207@ns.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2005-07-24 20:37:18 | Re: For review: Server instrumentation patch |
Previous Message | Tom Lane | 2005-07-24 20:24:57 | Re: For review: Server instrumentation patch |