Re: Dumping an Extension's Script

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

In response to

Responses

Browse pgsql-hackers by date

  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