From 50fc694e43742ce3d04a5e9f708432cb022c5f0d Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 29 Jan 2020 18:42:43 -0500 Subject: Invent "trusted" extensions, and remove the pg_pltemplate catalog. This patch creates a new extension property, "trusted". An extension that's marked that way in its control file can be installed by a non-superuser who has the CREATE privilege on the current database, even if the extension contains objects that normally would have to be created by a superuser. The objects within the extension will (by default) be owned by the bootstrap superuser, but the extension itself will be owned by the calling user. This allows replicating the old behavior around trusted procedural languages, without all the special-case logic in CREATE LANGUAGE. We have, however, chosen to loosen the rules slightly: formerly, only a database owner could take advantage of the special case that allowed installation of a trusted language, but now anyone who has CREATE privilege can do so. Having done that, we can delete the pg_pltemplate catalog, moving the knowledge it contained into the extension script files for the various PLs. This ends up being no change at all for the in-core PLs, but it is a large step forward for external PLs: they can now have the same ease of installation as core PLs do. The old "trusted PL" behavior was only available to PLs that had entries in pg_pltemplate, but now any extension can be marked trusted if appropriate. This also removes one of the stumbling blocks for our Python 2 -> 3 migration, since the association of "plpythonu" with Python 2 is no longer hard-wired into pg_pltemplate's initial contents. Exactly where we go from here on that front remains to be settled, but one problem is fixed. Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others. Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us --- doc/src/sgml/catalogs.sgml | 122 +++------------------------------ doc/src/sgml/ddl.sgml | 8 ++- doc/src/sgml/extend.sgml | 37 ++++++++++ doc/src/sgml/plpython.sgml | 2 +- doc/src/sgml/ref/create_extension.sgml | 17 ++++- doc/src/sgml/ref/create_language.sgml | 113 ++++++++---------------------- doc/src/sgml/xplang.sgml | 2 +- 7 files changed, 96 insertions(+), 205 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 85ac79f07ec..a10b66569b9 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -225,11 +225,6 @@ information about partition key of tables - - pg_pltemplate - template data for procedural languages - - pg_policy row-security policies @@ -4911,113 +4906,6 @@ SCRAM-SHA-256$<iteration count>:&l - - <structname>pg_pltemplate</structname> - - - pg_pltemplate - - - - The catalog pg_pltemplate stores - template information for procedural languages. - A template for a language allows the language to be created in a - particular database by a simple CREATE LANGUAGE command, - with no need to specify implementation details. - - - - Unlike most system catalogs, pg_pltemplate - is shared across all databases of a cluster: there is only one - copy of pg_pltemplate per cluster, not - one per database. This allows the information to be accessible in - each database as it is needed. - - - - <structname>pg_pltemplate</structname> Columns - - - - - Name - Type - Description - - - - - - tmplname - name - Name of the language this template is for - - - - tmpltrusted - boolean - True if language is considered trusted - - - - tmpldbacreate - boolean - True if language may be created by a database owner - - - - tmplhandler - text - Name of call handler function - - - - tmplinline - text - Name of anonymous-block handler function, or null if none - - - - tmplvalidator - text - Name of validator function, or null if none - - - - tmpllibrary - text - Path of shared library that implements language - - - - tmplacl - aclitem[] - Access privileges for template (not actually used) - - - - -
- - - There are not currently any commands that manipulate procedural language - templates; to change the built-in information, a superuser must modify - the table using ordinary INSERT, DELETE, - or UPDATE commands. - - - - - It is likely that pg_pltemplate will be removed in some - future release of PostgreSQL, in favor of - keeping this knowledge about procedural languages in their respective - extension installation scripts. - - - - - - <structname>pg_policy</structname> @@ -8519,7 +8407,15 @@ SCRAM-SHA-256$<iteration count>:&l superuser bool - True if only superusers are allowed to install this extension + True if only superusers are allowed to install this extension + (but see trusted) + + + + trusted + bool + True if the extension can be installed by non-superusers + with appropriate privileges diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 3546e390a8f..8d3a0d1c223 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1742,6 +1742,7 @@ REVOKE ALL ON accounts FROM PUBLIC; For databases, allows new schemas and publications to be created within + the database, and allows trusted extensions to be installed within the database. @@ -1753,8 +1754,11 @@ REVOKE ALL ON accounts FROM PUBLIC; For tablespaces, allows tables, indexes, and temporary files to be created within the tablespace, and allows databases to be created that - have the tablespace as their default tablespace. (Note that revoking - this privilege will not alter the placement of existing objects.) + have the tablespace as their default tablespace. + + + Note that revoking this privilege will not alter the existence or + location of existing objects. diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml index a3046f22d05..ffe068b0c4c 100644 --- a/doc/src/sgml/extend.sgml +++ b/doc/src/sgml/extend.sgml @@ -576,6 +576,31 @@ version. If it is set to false, just the privileges required to execute the commands in the installation or update script are required. + This should normally be set to true if any of the + script commands require superuser privileges. (Such commands would + fail anyway, but it's more user-friendly to give the error up front.) + + + + + + trusted (boolean) + + + This parameter, if set to true (which is not the + default), allows some non-superusers to install an extension that + has superuser set to true. + Specifically, installation will be permitted for anyone who has + CREATE privilege on the current database. + When the user executing CREATE EXTENSION is not + a superuser but is allowed to install by virtue of this parameter, + then the installation or update script is run as the bootstrap + superuser, not as the calling user. + This parameter is irrelevant if superuser is + false. + Generally, this should not be set true for extensions that could + allow access to otherwise-superuser-only abilities, such as + filesystem access. @@ -641,6 +666,18 @@ extension, a state of affairs that's a bit tedious to recover from. + + If the extension script contains the + string @extowner@, that string is replaced with the + (suitably quoted) name of the user calling CREATE + EXTENSION or ALTER EXTENSION. Typically + this feature is used by extensions that are marked trusted to assign + ownership of selected objects to the calling user rather than the + bootstrap superuser. (One should be careful about doing so, however. + For example, assigning ownership of a C-language function to a + non-superuser would create a privilege escalation path for that user.) + + While the script files can contain any characters allowed by the specified encoding, control files should contain only plain ASCII, because there diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml index 7bdaf76bbad..1921915b172 100644 --- a/doc/src/sgml/plpython.sgml +++ b/doc/src/sgml/plpython.sgml @@ -153,7 +153,7 @@ Daredevils, who want to build a Python-3-only operating system environment, can change the contents of - pg_pltemplate + plpythonu's extension control and script files to make plpythonu be equivalent to plpython3u, keeping in mind that this would make their installation incompatible with most of the rest diff --git a/doc/src/sgml/ref/create_extension.sgml b/doc/src/sgml/ref/create_extension.sgml index 36837f927d4..d76ac3e18d0 100644 --- a/doc/src/sgml/ref/create_extension.sgml +++ b/doc/src/sgml/ref/create_extension.sgml @@ -47,14 +47,25 @@ CREATE EXTENSION [ IF NOT EXISTS ] extension_name - Loading an extension requires the same privileges that would be - required to create its component objects. For most extensions this - means superuser or database owner privileges are needed. The user who runs CREATE EXTENSION becomes the owner of the extension for purposes of later privilege checks, as well as the owner of any objects created by the extension's script. + + Loading an extension ordinarily requires the same privileges that would + be required to create its component objects. For many extensions this + means superuser privileges are needed. + However, if the extension is marked trusted in + its control file, then it can be installed by any user who has + CREATE privilege on the current database. + In this case the extension object itself will be owned by the calling + user, but the contained objects will be owned by the bootstrap superuser + (unless the extension's script explicitly assigns them to the calling + user). This configuration gives the calling user the right to drop the + extension, but not to modify individual objects within it. + + diff --git a/doc/src/sgml/ref/create_language.sgml b/doc/src/sgml/ref/create_language.sgml index 13b28b1cccb..af9d115edd5 100644 --- a/doc/src/sgml/ref/create_language.sgml +++ b/doc/src/sgml/ref/create_language.sgml @@ -21,9 +21,9 @@ PostgreSQL documentation -CREATE [ OR REPLACE ] [ PROCEDURAL ] LANGUAGE name CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE name HANDLER call_handler [ INLINE inline_handler ] [ VALIDATOR valfunction ] +CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE name @@ -37,21 +37,6 @@ CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE - not CREATE LANGUAGE. Direct use of - CREATE LANGUAGE should now be confined to - extension installation scripts. If you have a bare - language in your database, perhaps as a result of an upgrade, - you can convert it to an extension using - CREATE EXTENSION langname FROM - unpackaged. - - - CREATE LANGUAGE effectively associates the language name with handler function(s) that are responsible for executing @@ -60,53 +45,32 @@ CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE pg_pltemplate - system catalog to determine the correct parameters. In the second form, - the user supplies the language parameters along with the language name. - The second form can be used to create a language that is not defined in - pg_pltemplate, but this approach is considered obsolescent. - - - - When the server finds an entry in the pg_pltemplate catalog - for the given language name, it will use the catalog data even if the - command includes language parameters. This behavior simplifies loading of - old dump files, which are likely to contain out-of-date information - about language support functions. + CREATE OR REPLACE LANGUAGE will either create a + new language, or replace an existing definition. If the language + already exists, its parameters are updated according to the command, + but the language's ownership and permissions settings do not change, + and any existing functions written in the language are assumed to still + be valid. - Ordinarily, the user must have the + One must have the PostgreSQL superuser privilege to - register a new language. However, the owner of a database can register - a new language within that database if the language is listed in - the pg_pltemplate catalog and is marked - as allowed to be created by database owners (tmpldbacreate - is true). The default is that trusted languages can be created - by database owners, but this can be adjusted by superusers by modifying - the contents of pg_pltemplate. - The creator of a language becomes its owner and can later - drop it, rename it, or assign it to a new owner. + register a new language or change an existing language's parameters. + However, once the language is created it is valid to assign ownership of + it to a non-superuser, who may then drop it, change its permissions, + rename it, or assign it to a new owner. (Do not, however, assign + ownership of the underlying C functions to a non-superuser; that would + create a privilege escalation path for that user.) - CREATE OR REPLACE LANGUAGE will either create a - new language, or replace an existing definition. If the language - already exists, its parameters are updated according to the values - specified or taken from pg_pltemplate, - but the language's ownership and permissions settings do not change, - and any existing functions written in the language are assumed to still - be valid. In addition to the normal privilege requirements for creating - a language, the user must be superuser or owner of the existing language. - The REPLACE case is mainly meant to be used to - ensure that the language exists. If the language has a - pg_pltemplate entry then REPLACE - will not actually change anything about an existing definition, except in - the unusual case where the pg_pltemplate entry - has been modified since the language was created. + The form of CREATE LANGUAGE that does not supply + any handler function is obsolete. For backwards compatibility with + old dump files, it is interpreted as CREATE EXTENSION. + That will work if the language has been packaged into an extension of + the same name, which is the conventional way to set up procedural + languages. @@ -218,12 +182,6 @@ CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE @@ -254,18 +212,6 @@ CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE Examples - The preferred way of creating any of the standard procedural languages - is just: - -CREATE LANGUAGE plperl; - - - - - For a language not known in the pg_pltemplate catalog, a - sequence such as this is needed: + A minimal sequence for creating a new procedural language is: CREATE FUNCTION plsample_call_handler() RETURNS language_handler AS '$libdir/plsample' LANGUAGE C; CREATE LANGUAGE plsample HANDLER plsample_call_handler; - + + Typically that would be written in an extension's creation script, + and users would do this to install the extension: + +CREATE EXTENSION plsample; + + diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml index 60e04307510..e647e2d3ef8 100644 --- a/doc/src/sgml/xplang.sgml +++ b/doc/src/sgml/xplang.sgml @@ -190,7 +190,7 @@ CREATE FUNCTION plperl_call_handler() RETURNS language_handler AS CREATE FUNCTION plperl_inline_handler(internal) RETURNS void AS - '$libdir/plperl' LANGUAGE C; + '$libdir/plperl' LANGUAGE C STRICT; CREATE FUNCTION plperl_validator(oid) RETURNS void AS '$libdir/plperl' LANGUAGE C STRICT; -- cgit v1.2.3