Re: dblink connection security

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Joe Conway" <mail(at)joeconway(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: dblink connection security
Date: 2007-07-09 04:49:37
Message-ID: 87fy3yb2qm.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Joe Conway" <mail(at)joeconway(dot)com> writes:

> Stephen Frost wrote:
>
>> I see.. So all the functions in untrusted languages that come with PG
>> initially should be checked over by every sysadmin when installing PG
>> every time... And the same for PostGIS, and all of the PL's that use
>> untrusted languages?
>
> There are none installed by default -- that's the point.

That's not a scalable approach. If you treat the mere installation of a
package as potentially making significant changes to the security model then
it makes a joke of our whole security infrastructure. We could just have said
you shouldn't create functions that you don't want public to have access to.

He has a point too. If a sysadmin has to audit the security implications of
every package when installing it that makes installing PostGIS a pretty
daunting task.

If on the other hand packages make the promise that they don't change the
security model by merely being installed then programmers or dependent modules
can request packages and dbas can be confident that installing them won't
introduce security holes. Isn't that a property software should have even if
it's just an add-on module?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2007-07-09 13:47:25 Re: dblink connection security
Previous Message Stephen Frost 2007-07-09 04:45:19 Re: dblink connection security