On Wed, 24 Jan 2007, Jeremy Drake wrote:
On Wed, 24 Jan 2007, Tom Lane wrote:
In detail, it'd look something like:
* For an untrusted language: must be superuser to either create or use
the language (no change from current rules). Ownership of the
pg_language entry is really
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
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Jeremy Drake wrote:
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
On Wed, 24 Jan 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Jeremy Drake wrote:
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
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Tom Lane wrote:
that there really needs to be *some* sort of privilege check here.
What that is and how to implement it are the hard parts.
So I guess it depends on what you mean by DBA. Perhaps the database
owner? Or some new
On Wed, 24 Jan 2007, Tom Lane wrote:
Not the DB owner. If you are worried about whether to allow use of PLs
it's almost certainly an installation-wide security concern, so I'd say
that the privilege has to flow from a superuser.
GRANT CREATE ON LANGUAGE feeding into a flag bit in pltemplate
On Wed, 24 Jan 2007, Tom Lane wrote:
In detail, it'd look something like:
* For an untrusted language: must be superuser to either create or use
the language (no change from current rules). Ownership of the
pg_language entry is really irrelevant, as is its ACL.
* For a trusted language:
