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
Index: src/backend/commands/proclang.c
===================================================================
RCS file: 
/home/jeremyd/local/postgres/cvsuproot/pgsql/src/backend/commands/proclang.c,v
retrieving revision 1.71
diff -c -r1.71 proclang.c
*** src/backend/commands/proclang.c     22 Jan 2007 01:35:20 -0000      1.71
--- src/backend/commands/proclang.c     24 Jan 2007 23:50:49 -0000
***************
*** 61,74 ****
        Oid                     funcargtypes[1];
  
        /*
-        * Check permission
-        */
-       if (!superuser())
-               ereport(ERROR,
-                               (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
-                                errmsg("must be superuser to create procedural 
language")));
- 
-       /*
         * Translate the language name and check that this language doesn't
         * already exist
         */
--- 61,66 ----
***************
*** 97,102 ****
--- 89,103 ----
                                        (errmsg("using pg_pltemplate 
information instead of CREATE LANGUAGE parameters")));
  
                /*
+                * Check permission
+                */
+               if (!pltemplate->tmpltrusted && !superuser())
+                       ereport(ERROR,
+                                       
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+                                        errmsg("must be superuser to create 
untrusted procedural language")));
+ 
+ 
+               /*
                 * Find or create the handler function, which we force to be in 
the
                 * pg_catalog schema.  If already present, it must have the 
correct
                 * return type.
***************
*** 189,194 ****
--- 190,203 ----
                                         errhint("The supported languages are 
listed in the pg_pltemplate system catalog.")));
  
                /*
+                * Check permission
+                */
+               if (!superuser())
+                       ereport(ERROR,
+                                       
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+                                        errmsg("must be superuser to create 
custom procedural language")));
+ 
+               /*
                 * Lookup the PL handler function and check that it is of the 
expected
                 * return type
                 */
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to