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 endswhen a person stops absentmindedly
writingthe old year on his checks.