Re: Dumping an Extension's Script

On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > Adding some *NON WRITABLE* per-cluster library directory doesn't seem to
> > be as controversion as other suggestions.
>
> Well, it means a per-initdb (user driven) location where to store binary
> files, ask Tom what he thinks about that with his Red Hat Packager… Hat.

I think it might be different if the directory is non-writable and
connot be made writable by user running postgres.

> >> 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.
>
> […please make sure you're not drinking (coffee) before reading further…]
>
> Now if we can't fix the executable files situation, what about making
> the C coded extensions not require an executable anymore? I'm thinking
> about studying what it would take exactly to write a PL/C where the
> PostgreSQL backend would basically compile the embedded C code at CREATE
> FUNCTION time and store bytecode or binary in the probin column.
>
> So, we're talking about a PL/C language, in-core or extension, where you
> could define say hstore without shipping any executable binary. Yeah,
> I'm crazy that way. Now I'll get back to the main thread…

Imo thats not a sensible thing to pursue.

It would seriously shorten the effort needed to run user-provided
code. Yes, you can execute unrestricted perl, python whatever already
but with selinux and similar things in place that won't allow you to run
your own binaries. And currently execute-or-write protection will
prevent you from executing compiled code. So you would have to disable
that as well...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services