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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org