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
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 |