On Sat, Apr 5, 2008 at 12:22 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: > "Aidan Van Dyk" <[EMAIL PROTECTED]> writes: > > > What if you didn't need super-user privileges to load "C" functions, on > > the conditions that: > > 1) There is no / in the obj_file filename (or some other "sanitizing" > > rules) > > 2) You're database owner > > That's an interesting idea. It has the property that no super-user is > required > to do any fiddling *inside* your database. That is, the ISP can just do > CREATE > DATABASE and then leave you have at it without having to deal with installing > modules or granting any permissions inside your database.
Maybe it didn't come across, but it's exactly what I've been suggesting in this thread, albeit a slightly different solution. My idea was to have an installed "module", and rather than allowing $database_owner to create C language functions based on what are really implementation details for the given extension, just allow them to say e.g. "install module postgis;" or equivalent - this would then run either some init function or an appropriately named and placed install script that would take care of everything. A module would be expected to provide an uninstall script, too, to allow "uninstall module foo" or whatever. Under this scenario end users don't need access to the install scripts, don't need to know the exact library name, and aren't given the ability to e.g. create C language functions in ways that weren't intended, like declaring one taking the wrong variable types or something. The sysadmin can trust the module to do the right thing - they don't have to trust the user. As far as getting sysadmins to install contrib, this then becomes really easy - just install them all by default and let database owners install them into their own dbs as they wish. > It also opens the door to .deb packagers being able to put pgfoundry modules > in the same space. No other suggestion has offered any help to anything > except > blessed contrib modules. Well, I actually was approaching the problem from the point of view of creating yum installable rpms - killing contrib was just a nice side effect :) > I would suggest a guc for the "safe" place and I would suggest it be a list > of > places. And I would suggest that for OS packagers they really want two > locations on that list, something like: > /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules > That way users can compile and install their own modules into /usr/local > without interfering with modules which come from OS packages. +1. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
