From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dumping an Extension's Script |
Date: | 2012-12-05 18:18:16 |
Message-ID: | 9316.1354731496@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> At the SQL level, extensions do live in a database. The only reason why
> we currently have them on the file system is binary executables (.so,
> .dylib, .dll). And those are not per database, not even per cluster, not
> even per major version, they are *per server*. It's something that makes
> me very sad, and that I want to have the chance to fix later, but that
> won't happen in 9.3, and certainly not in that very patch
I think you're wasting your time to imagine that that case will ever be
"fixed". Allowing the server to scribble on executable files would set
off all kinds of security alarm bells, and rightly so. If Postgres ever
did ship with such a thing, I rather imagine that I'd be required to
patch it out of Red Hat releases (not that SELinux wouldn't prevent
it from happening anyway).
I do see an argument for allowing SQL-only extensions to be installed
this way, since that doesn't allow the execution of anything the user
couldn't execute anyway. There's no need to worry about anything except
control and script files though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-12-05 18:23:29 | Re: Dumping an Extension's Script |
Previous Message | Heikki Linnakangas | 2012-12-05 18:15:42 | Re: Dumping an Extension's Script |