Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] unprivileged contrib and pl install

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Patches <pgsql-patches(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] unprivileged contrib and pl install
Date: 2007-01-25 07:15:20
Message-ID: Pine.BSO.4.64.0701242305320.23712@resin.csoft.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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:
>
> * if pg_pltemplate.something is ON: either a superuser or the current
> DB's owner can CREATE the language.  In either case the pg_language
> entry will be marked as owned by the DB owner (pg_database.datdba),
> which means that subsequently he (or a superuser) can grant or deny
> USAGE within his DB.
>
> * if pg_pltemplate.something is OFF: must be superuser to CREATE the
> language; subsequently it will be owned by you, so only you or another
> superuser can grant or deny USAGE (same behavior as currently).

I think I have what is described here implemented in this patch, so that
it can be better understood.  Thoughts?


-- 
Nobody said computers were going to be polite.

Attachment: language_priv_changes.patch
Description: text/plain (15.1 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Gavin SherryDate: 2007-01-25 07:18:06
Subject: Re: pg_get_domaindef
Previous:From: Tom LaneDate: 2007-01-25 07:06:26
Subject: Re: pg_get_domaindef

pgsql-patches by date

Next:From: Gavin SherryDate: 2007-01-25 07:18:06
Subject: Re: pg_get_domaindef
Previous:From: Tom LaneDate: 2007-01-25 07:06:26
Subject: Re: pg_get_domaindef

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group