Re: [HACKERS] unprivileged contrib and pl install (formerly tsearch - Mailing list pgsql-patches

From Jeremy Drake
Subject Re: [HACKERS] unprivileged contrib and pl install (formerly tsearch
Date
Msg-id Pine.BSO.4.64.0701241600080.23712@resin.csoft.net
Whole thread Raw
Responses Re: [HACKERS] unprivileged contrib and pl install (formerly tsearch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Wed, 24 Jan 2007, Jeremy Drake wrote:

> On Wed, 24 Jan 2007, Martijn van Oosterhout wrote:
>
> > Something I've wondered about before is the concept of having installed
> > Modules in the system. Let's say for example that while compiling
> > postgres it compiled the modules in contrib also and installed them in
> > a modules directory.
> >
> > Once installed there, unpriviledged users could say "INSTALL foo" and
> > it would install the module, even if they do not have the permissions
> > to create them themselves.
>
> That would be great, and also it would be great to be able to CREATE
> LANGUAGE as a regular user for a trusted pl that is already
> compiled/installed.

Something like the attached (simple) change to allow CREATE LANGUAGE by
unprivileged users for trusted languages already present in pg_pltemplate.
I'm not quite sure how one would go about doing the module thing, I think
that would be more complex.  Something simple like allowing creation of C
language functions in libraries in $libdir would probably not be
sufficient, because an unprivileged user could create functions that have
the wrong paramters or return values and crash things pretty good that
way.  Any ideas how this would work?  Perhaps a sql script in
sharedir could be run by the backend as though by a superuser...

--
Ed Sullivan will be around as long as someone else has talent.
        -- Fred Allen

Attachment

pgsql-patches by date:

Previous
From: Guido Goldstein
Date:
Subject: Fix for bug in plpython bool type conversion
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] unprivileged contrib and pl install (formerly tsearch