On 2013-09-14 22:15:58 +0200, Dimitri Fontaine wrote:
> The way they make that safe is by using cgroups and SELinux, IIUC.
>
> We can attack the problem in several ways:
>
> - have an initdb switch to tweak the library path per cluster,
That sounds like an utterly horrible idea without any advantages.
> - have a superuser-only GUC to tweak the library path,
Hm. I think we might want to make it a PGC_POSTMASTER/postgresql.conf
variable instead. Is that stopping usecases of yours?
That's what I vote for.
> - consider on-disk extension as templates and move their module files
> somewhere private in $PGDATA and load the code from there
I don't understand what that does to address the security concerns.
> That would allow OS upgrades not to impact running instances until
> they do ALTER EXTENSION UPDATE; and allowing co-existence of
> different versions of the same extension in different clusters of
> the same major version, and maybe in separate databases of the same
> cluster in some cases (depends on the extension's module specifics),
And it would be an upgrade nightmare.
> This proposal comes with no patch because I think we are able to
> understand it without that, so that it would only be a waste of
> everybody's time to attach code for a random solution on the list here
> to that email. Or consider that the fourth point is currently the only
> one addressed in this very proposal…
Yea, the code issue seem to be small here.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services