From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Jeremy Drake <pgsql(at)jdrake(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Subject: | Re: modules |
Date: | 2008-04-04 15:03:01 |
Message-ID: | 20080404150301.GH6497@yugib.highrise.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
* Andrew Dunstan <andrew(at)dunslane(dot)net> [080404 10:17]:
> Aidan Van Dyk wrote:
> >This was simply about changing the user permissions needed to run CREATE
> >FUNCTION ... LANGUAGE "C" so that distros/packages could have whatever
> >module they want packaged (in system RPM/DEB/PKG context) and available
> >on the system in a way that databases owners could install them into
> >their PostgreSQL database (using the current psql < earthdistance.sql
> >methods) without getting ISP/superuser assistance.
> That's not going to happen, at least not like that - the security
> implications are just horrible. We have recently relaxed the rules
> relating to installation of trusted languages by database owners. But to
> extend that to modules in general we'd need some way of designating
> modules as safe or not.
Excatly - this was just a one simple method of marking modules as
"safe"; if the object files are found in the "safe" place (possibly the
location of pg_config --pkglibdir, possibly elsewhere, specified by a
GUC, possibly something else), then they could be considered "safe" for
the database owner to use as a LANGUAGE "C" definition. The "safe"
location could be somewhere else.
Like I said earlier, this changes the game (that Jermery original said
was the problem - namely that a module is useless if it's not installed,
and he can't install it unless he's superuser) only slightly. It's just
a method for packagers/distros/sysadmins to mark modules as safe. If
the packages (rpm/deb/pkg context) are installed on the system, and the
files are in the location considered to mark them safe), then any DB
owner could install them into their DB.
It's just one possible way to mark modules as "safe". Just as another
method for used for languages was to use a system table like
pg_pltemplate. But it's something that I think *may* be better than
pg_pltemplate, because pg_pltemplate re-enforces the notion that only
things in core (and installed in core by default) can be considered
safe, because really, how is some dpkg installation of plruby or plperl
or pljava automatically going to get it's info into pl_pltemplate
without specific knowledge of the port your cluster (or all your
clusters) are on, superuser connection details, etc.
But maybe some system table *is* the way to make object files as safe,
so a super-user *is* required to add some row to some table to mark it
as safe.
I'm looking for *some* way to make a way for 3rd party modules to be
considered "safe" so somebody (non-superuser) can install them into a PG
database.
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2008-04-04 15:05:44 | Re: modules |
Previous Message | Bhat, Suma | 2008-04-04 14:21:12 | Question about pg_catalog.pg_trigger. |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2008-04-04 15:05:44 | Re: modules |
Previous Message | Andrew Dunstan | 2008-04-04 14:17:30 | Re: modules |