* Jeremy Drake (pgsql@jdrake.com) wrote:
> The crux of this seems to be two-fold:
> 1. If dblink is installed, an untrusted user could use it to gain
> privileges, either using trust/ident auth (you have a superuser named
> after the account the postmaster is runing as), or can be scripted to
> brute force passwords.
The dblink w/ ident case is at least somewhat interesting since, iirc
anyway, if you install dblink it comes with permissions for anyone to
run it. That's pretty ugly if your PG superuser is the same user
PostgreSQL runs as and you're using ident (which is quite common, esp.
over unix sockets). The answer here being, don't allow just anyone to
run dblink.
> 2. If you are a superuser, you can gain access to the external system, ie,
> by creating C language functions.
Which, as an issue, is pretty much resolved in 8.2 anyway... You'd have
to be able to compile and/or upload new libraries to the system w/ 8.2
since the PG_MODULE_MAGIC is required now.
> Neither of these are news to me, but maybe some new postgres admin will
> read it and figure out to disable trust auth and not to let untrusted
> users call dblink (either not install it or REVOKE the rights to call it).
I'm strongly tempted to say this should be set up as the default for
dblink, if it's not too hard to implement (I'd expect there's already a
.sql which does the in-db create function and whatnot, just revoke all
from it after it's created and tell people to create views using it
instead as superuser).
Thanks,
Stephen