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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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 Content-Type Size
language_priv_changes.patch text/plain 15.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2007-01-25 07:18:06 Re: pg_get_domaindef
Previous Message Tom Lane 2007-01-25 07:06:26 Re: pg_get_domaindef

Browse pgsql-patches by date

  From Date Subject
Next Message Gavin Sherry 2007-01-25 07:18:06 Re: pg_get_domaindef
Previous Message Tom Lane 2007-01-25 07:06:26 Re: pg_get_domaindef