Re: dblink connection security

Gregory Stark wrote:
> "Joe Conway" <mail(at)joeconway(dot)com> writes:
>
>> Stephen Frost wrote:
>>> * Joe Conway (mail(at)joeconway(dot)com) wrote:
>>>> There are none installed by default -- that's the point.
>>> Uhh... None what? Functions in untrusted languages? That's certainly
>>> not the case, there's a whole slew of them, from boolin to
>>> generate_series and beyond. They're available to regular users, even!
>> Get serious. Internal functions are specifically designed and maintained to be
>> safe within the confines of the database security model. We are discussing
>> extensions to the core, all of which must be installed by choice, by a superuser.
>
> That doesn't mean they shouldn't be concerned with security.

Of course they should be concerned with security. Its the job of the
DBA/superuser to be concerned with security, and therefore they ought to
know what the implications are for what they install, before they
install it.

> Consider dblink as an entirely separate product which depends on Postgres the
> way Postgres depends on the OS. We discussing how the dblink software should
> behave when installed with *its* default configuration.

And the the security escalation scenario, which is a consequence of the
DBA's inadequate understanding of the security setup of the system in
the first place, has now been closed for them. Granted, this was an easy
enough mistake to make, so I agree that what we've done to close it is a
good thing. But if you know of a security risk related to using libpq
with a password authenticated connection, let's hear it.

Joe