Re: [pgsql-patches] unprivileged 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 Hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [pgsql-patches] unprivileged pl install
Date: 2007-01-25 23:38:31
Message-ID: Pine.BSO.4.64.0701251523510.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:

> * 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.

What happens on ALTER DATABASE ALTER OWNER? Does the ownership of the
language change to the new datdba or stay the old one?

If the CREATE LANGUAGE results in creating the handler and validation
funcs, who should own them? At the moment it is the user doing the CREATE
LANGUAGE, but what does that mean? Can they then do odd things to the
permissions of the procs, such as denying execute on them, to break other
user's usage of the language, or does the perms on a language pre-empt the
perms on the func?

What happens if pg_pltemplate.something changes after the language is
created? The datdba would continue to own the language, and can change
permissions and drop it, but could not recreate it. I assume if the
superuser wanted to revoke the ability for database owners to create that
language they would remove it from people's databases who already have it.

>
> * 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).

What if pg_pltemplate.something is OFF, the language is CREATEd by a
superuser, and then pg_pltemplate is set ON? The language is now owned by
a superuser, so the db owner could not manipulate it.

The patch I put together adds an owner to pg_language. Should there be an
ALTER LANGUAGE OWNER TO command added as well. Thinking about these
conditions I have described here, it seems to me there should be.

Or there could not be an owner for a language and who the owner is depends
on the conditions listed. But then permissions checks for languages
would depend on pg_pltemplate, which seems less than clear or ideal to me.
Besides which, when the acl is initalized from NULL to a value, it depends
on who the owner is. It would need to be changed as well when the owner
changing conditions change.

I think that an ALTER LANGUAGE OWNER TO is the proper response to these
things, and unless I hear otherwise I will attempt to add this to my
patch.

--
Checkuary, n.:
The thirteenth month of the year. Begins New Year's Day and ends
when a person stops absentmindedly writing the old year on his checks.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2007-01-25 23:47:39 Re: Proposal: Commit timestamp
Previous Message Jan Wieck 2007-01-25 23:33:07 Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled

Browse pgsql-patches by date

  From Date Subject
Next Message Jeremy Drake 2007-01-26 01:48:37 Re: [HACKERS] unprivileged pl install
Previous Message Jeremy Drake 2007-01-25 23:23:31 Re: [HACKERS] unprivileged contrib and pl install