diff options
Diffstat (limited to 'doc/src/sgml')
| -rw-r--r-- | doc/src/sgml/installation.sgml | 5 | ||||
| -rw-r--r-- | doc/src/sgml/plperl.sgml | 61 | ||||
| -rw-r--r-- | doc/src/sgml/pltcl.sgml | 44 | ||||
| -rw-r--r-- | doc/src/sgml/release-7.4.sgml | 37 | ||||
| -rw-r--r-- | doc/src/sgml/release-8.0.sgml | 37 | ||||
| -rw-r--r-- | doc/src/sgml/release-8.1.sgml | 37 | ||||
| -rw-r--r-- | doc/src/sgml/release-8.2.sgml | 37 | ||||
| -rw-r--r-- | doc/src/sgml/release-8.3.sgml | 37 | ||||
| -rw-r--r-- | doc/src/sgml/release-8.4.sgml | 37 |
9 files changed, 305 insertions, 27 deletions
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 1bc30975a45..9e339192b80 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -169,6 +169,11 @@ su - postgres recent <productname>Perl</productname> versions, but it was not in earlier versions, and in any case it is the choice of whomever installed Perl at your site. + If you intend to make more than incidental use of + <application>PL/Perl</application>, you should ensure that the + <productname>Perl</productname> installation was built with the + <literal>usemultiplicity</> option enabled (<literal>perl -V</> + will show whether this is the case). </para> <para> diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml index d1eb8e1bf9a..7ff49e7be26 100644 --- a/doc/src/sgml/plperl.sgml +++ b/doc/src/sgml/plperl.sgml @@ -41,7 +41,7 @@ <para> Users of source packages must specially enable the build of PL/Perl during the installation process. (Refer to <xref - linkend="install-short"> for more information.) Users of + linkend="installation"> for more information.) Users of binary packages might find PL/Perl in a separate subpackage. </para> </note> @@ -83,7 +83,7 @@ $$ LANGUAGE plperl; most convenient to use dollar quoting (see <xref linkend="sql-syntax-dollar-quoting">) for the string constant. If you choose to use escape string syntax <literal>E''</>, - you must double the single quote marks (<literal>'</>) and backslashes + you must double any single quote marks (<literal>'</>) and backslashes (<literal>\</>) used in the body of the function (see <xref linkend="sql-syntax-strings">). </para> @@ -679,6 +679,23 @@ $$ LANGUAGE plperl; <literal>return $_SHARED{myquote}->($_[0]);</literal> at the expense of readability.) </para> + + <para> + For security reasons, PL/Perl executes functions called by any one SQL role + in a separate Perl interpreter for that role. This prevents accidental or + malicious interference by one user with the behavior of another user's + PL/Perl functions. Each such interpreter has its own value of the + <varname>%_SHARED</varname> variable and other global state. Thus, two + PL/Perl functions will share the same value of <varname>%_SHARED</varname> + if and only if they are executed by the same SQL role. In an application + wherein a single session executes code under multiple SQL roles (via + <literal>SECURITY DEFINER</> functions, use of <command>SET ROLE</>, etc) + you may need to take explicit steps to ensure that PL/Perl functions can + share data via <varname>%_SHARED</varname>. To do that, make sure that + functions that should communicate are owned by the same user, and mark + them <literal>SECURITY DEFINER</>. You must of course take care that + such functions can't be used to do anything unintended. + </para> </sect1> <sect1 id="plperl-trusted"> @@ -746,21 +763,31 @@ $$ LANGUAGE plperl; </para> <note> - <para> - For security reasons, to stop a leak of privileged operations from - <application>PL/PerlU</> to <application>PL/Perl</>, these two languages - have to run in separate instances of the Perl interpreter. If your - Perl installation has been appropriately compiled, this is not a problem. - However, not all installations are compiled with the requisite flags. - If <productname>PostgreSQL</> detects that this is the case then it will - not start a second interpreter, but instead create an error. In - consequence, in such an installation, you cannot use both - <application>PL/PerlU</> and <application>PL/Perl</> in the same backend - process. The remedy for this is to obtain a Perl installation created - with the appropriate flags, namely either <literal>usemultiplicity</> or - both <literal>usethreads</> and <literal>useithreads</>. - For more details,see the <literal>perlembed</> manual page. - </para> + <para> + While <application>PL/Perl</> functions run in a separate Perl + interpreter for each SQL role, all <application>PL/PerlU</> functions + executed in a given session run in a single Perl interpreter (which is + not any of the ones used for <application>PL/Perl</> functions). + This allows <application>PL/PerlU</> functions to share data freely, + but no communication can occur between <application>PL/Perl</> and + <application>PL/PerlU</> functions. + </para> + </note> + + <note> + <para> + Perl cannot support multiple interpreters within one process unless + it was built with the appropriate flags, namely either + <literal>usemultiplicity</> or <literal>useithreads</>. + (<literal>usemultiplicity</> is preferred unless you actually need + to use threads. For more details, see the + <citerefentry><refentrytitle>perlembed</></citerefentry> man page.) + If <application>PL/Perl</> is used with a copy of Perl that was not built + this way, then it is only possible to have one Perl interpreter per + session, and so any one session can only execute either + <application>PL/PerlU</> functions, or <application>PL/Perl</> functions + that are all called by the same SQL role. + </para> </note> </sect1> diff --git a/doc/src/sgml/pltcl.sgml b/doc/src/sgml/pltcl.sgml index 73bffd64682..a8de38bed3f 100644 --- a/doc/src/sgml/pltcl.sgml +++ b/doc/src/sgml/pltcl.sgml @@ -215,14 +215,36 @@ $$ LANGUAGE pltcl; Sometimes it is useful to have some global data that is held between two calls to a function or is shared between different functions. - This is easily done since - all PL/Tcl functions executed in one session share the same - safe Tcl interpreter. So, any global Tcl variable is accessible to - all PL/Tcl function calls and will persist for the duration of the - SQL session. (Note that <application>PL/TclU</> functions likewise share - global data, but they are in a different Tcl interpreter and cannot - communicate with PL/Tcl functions.) + This is easily done in PL/Tcl, but there are some restrictions that + must be understood. </para> + + <para> + For security reasons, PL/Tcl executes functions called by any one SQL + role in a separate Tcl interpreter for that role. This prevents + accidental or malicious interference by one user with the behavior of + another user's PL/Tcl functions. Each such interpreter will have its own + values for any <quote>global</> Tcl variables. Thus, two PL/Tcl + functions will share the same global variables if and only if they are + executed by the same SQL role. In an application wherein a single + session executes code under multiple SQL roles (via <literal>SECURITY + DEFINER</> functions, use of <command>SET ROLE</>, etc) you may need to + take explicit steps to ensure that PL/Tcl functions can share data. To + do that, make sure that functions that should communicate are owned by + the same user, and mark them <literal>SECURITY DEFINER</>. You must of + course take care that such functions can't be used to do anything + unintended. + </para> + + <para> + All PL/TclU functions used in a session execute in the same Tcl + interpreter, which of course is distinct from the interpreter(s) + used for PL/Tcl functions. So global data is automatically shared + between PL/TclU functions. This is not considered a security risk + because all PL/TclU functions execute at the same trust level, + namely that of a database superuser. + </para> + <para> To help protect PL/Tcl functions from unintentionally interfering with each other, a global @@ -232,7 +254,9 @@ $$ LANGUAGE pltcl; <literal>GD</> be used for persistent private data of a function. Use regular Tcl global variables only for values that you specifically intend to be shared among - multiple functions. + multiple functions. (Note that the <literal>GD</> arrays are only + global within a particular interpreter, so they do not bypass the + security restrictions mentioned above.) </para> <para> @@ -692,8 +716,8 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab exists, the module <literal>unknown</> is fetched from the table and loaded into the Tcl interpreter immediately before the first execution of a PL/Tcl function in a database session. (This - happens separately for PL/Tcl and PL/TclU, if both are used, - because separate interpreters are used for the two languages.) + happens separately for each Tcl interpreter, if more than one is + used in a session; see <xref linkend="pltcl-global">.) </para> <para> While the <literal>unknown</> module could actually contain any diff --git a/doc/src/sgml/release-7.4.sgml b/doc/src/sgml/release-7.4.sgml index 2c52be70064..226275bf320 100644 --- a/doc/src/sgml/release-7.4.sgml +++ b/doc/src/sgml/release-7.4.sgml @@ -39,6 +39,43 @@ <listitem> <para> + Use a separate interpreter for each calling SQL userid in PL/Perl and + PL/Tcl (Tom Lane) + </para> + + <para> + This change prevents security problems that can be caused by subverting + Perl or Tcl code that will be executed later in the same session under + another SQL user identity (for example, within a <literal>SECURITY + DEFINER</> function). Most scripting languages offer numerous ways that + that might be done, such as redefining standard functions or operators + called by the target function. Without this change, any SQL user with + Perl or Tcl language usage rights can do essentially anything with the + SQL privileges of the target function's owner. + </para> + + <para> + The cost of this change is that intentional communication among Perl + and Tcl functions becomes more difficult. To provide an escape hatch, + PL/PerlU and PL/TclU functions continue to use only one interpreter + per session. This is not considered a security issue since all such + functions execute at the trust level of a database superuser already. + </para> + + <para> + It is likely that third-party procedural languages that claim to offer + trusted execution have similar security issues. We advise contacting + the authors of any PL you are depending on for security-critical + purposes. + </para> + + <para> + Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433). + </para> + </listitem> + + <listitem> + <para> Prevent possible crashes in <function>pg_get_expr()</> by disallowing it from being called with an argument that is not one of the system catalog columns it's intended to be used with diff --git a/doc/src/sgml/release-8.0.sgml b/doc/src/sgml/release-8.0.sgml index ae2b3c04cf7..f35cb61f419 100644 --- a/doc/src/sgml/release-8.0.sgml +++ b/doc/src/sgml/release-8.0.sgml @@ -39,6 +39,43 @@ <listitem> <para> + Use a separate interpreter for each calling SQL userid in PL/Perl and + PL/Tcl (Tom Lane) + </para> + + <para> + This change prevents security problems that can be caused by subverting + Perl or Tcl code that will be executed later in the same session under + another SQL user identity (for example, within a <literal>SECURITY + DEFINER</> function). Most scripting languages offer numerous ways that + that might be done, such as redefining standard functions or operators + called by the target function. Without this change, any SQL user with + Perl or Tcl language usage rights can do essentially anything with the + SQL privileges of the target function's owner. + </para> + + <para> + The cost of this change is that intentional communication among Perl + and Tcl functions becomes more difficult. To provide an escape hatch, + PL/PerlU and PL/TclU functions continue to use only one interpreter + per session. This is not considered a security issue since all such + functions execute at the trust level of a database superuser already. + </para> + + <para> + It is likely that third-party procedural languages that claim to offer + trusted execution have similar security issues. We advise contacting + the authors of any PL you are depending on for security-critical + purposes. + </para> + + <para> + Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433). + </para> + </listitem> + + <listitem> + <para> Prevent possible crashes in <function>pg_get_expr()</> by disallowing it from being called with an argument that is not one of the system catalog columns it's intended to be used with diff --git a/doc/src/sgml/release-8.1.sgml b/doc/src/sgml/release-8.1.sgml index 37e3751c0e1..34b3022d05d 100644 --- a/doc/src/sgml/release-8.1.sgml +++ b/doc/src/sgml/release-8.1.sgml @@ -39,6 +39,43 @@ <listitem> <para> + Use a separate interpreter for each calling SQL userid in PL/Perl and + PL/Tcl (Tom Lane) + </para> + + <para> + This change prevents security problems that can be caused by subverting + Perl or Tcl code that will be executed later in the same session under + another SQL user identity (for example, within a <literal>SECURITY + DEFINER</> function). Most scripting languages offer numerous ways that + that might be done, such as redefining standard functions or operators + called by the target function. Without this change, any SQL user with + Perl or Tcl language usage rights can do essentially anything with the + SQL privileges of the target function's owner. + </para> + + <para> + The cost of this change is that intentional communication among Perl + and Tcl functions becomes more difficult. To provide an escape hatch, + PL/PerlU and PL/TclU functions continue to use only one interpreter + per session. This is not considered a security issue since all such + functions execute at the trust level of a database superuser already. + </para> + + <para> + It is likely that third-party procedural languages that claim to offer + trusted execution have similar security issues. We advise contacting + the authors of any PL you are depending on for security-critical + purposes. + </para> + + <para> + Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433). + </para> + </listitem> + + <listitem> + <para> Prevent possible crashes in <function>pg_get_expr()</> by disallowing it from being called with an argument that is not one of the system catalog columns it's intended to be used with diff --git a/doc/src/sgml/release-8.2.sgml b/doc/src/sgml/release-8.2.sgml index f4b0056f6f8..89431c31f4f 100644 --- a/doc/src/sgml/release-8.2.sgml +++ b/doc/src/sgml/release-8.2.sgml @@ -33,6 +33,43 @@ <listitem> <para> + Use a separate interpreter for each calling SQL userid in PL/Perl and + PL/Tcl (Tom Lane) + </para> + + <para> + This change prevents security problems that can be caused by subverting + Perl or Tcl code that will be executed later in the same session under + another SQL user identity (for example, within a <literal>SECURITY + DEFINER</> function). Most scripting languages offer numerous ways that + that might be done, such as redefining standard functions or operators + called by the target function. Without this change, any SQL user with + Perl or Tcl language usage rights can do essentially anything with the + SQL privileges of the target function's owner. + </para> + + <para> + The cost of this change is that intentional communication among Perl + and Tcl functions becomes more difficult. To provide an escape hatch, + PL/PerlU and PL/TclU functions continue to use only one interpreter + per session. This is not considered a security issue since all such + functions execute at the trust level of a database superuser already. + </para> + + <para> + It is likely that third-party procedural languages that claim to offer + trusted execution have similar security issues. We advise contacting + the authors of any PL you are depending on for security-critical + purposes. + </para> + + <para> + Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433). + </para> + </listitem> + + <listitem> + <para> Prevent possible crashes in <function>pg_get_expr()</> by disallowing it from being called with an argument that is not one of the system catalog columns it's intended to be used with diff --git a/doc/src/sgml/release-8.3.sgml b/doc/src/sgml/release-8.3.sgml index eac868f3f15..0f4d44f9c5a 100644 --- a/doc/src/sgml/release-8.3.sgml +++ b/doc/src/sgml/release-8.3.sgml @@ -33,6 +33,43 @@ <listitem> <para> + Use a separate interpreter for each calling SQL userid in PL/Perl and + PL/Tcl (Tom Lane) + </para> + + <para> + This change prevents security problems that can be caused by subverting + Perl or Tcl code that will be executed later in the same session under + another SQL user identity (for example, within a <literal>SECURITY + DEFINER</> function). Most scripting languages offer numerous ways that + that might be done, such as redefining standard functions or operators + called by the target function. Without this change, any SQL user with + Perl or Tcl language usage rights can do essentially anything with the + SQL privileges of the target function's owner. + </para> + + <para> + The cost of this change is that intentional communication among Perl + and Tcl functions becomes more difficult. To provide an escape hatch, + PL/PerlU and PL/TclU functions continue to use only one interpreter + per session. This is not considered a security issue since all such + functions execute at the trust level of a database superuser already. + </para> + + <para> + It is likely that third-party procedural languages that claim to offer + trusted execution have similar security issues. We advise contacting + the authors of any PL you are depending on for security-critical + purposes. + </para> + + <para> + Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433). + </para> + </listitem> + + <listitem> + <para> Prevent possible crashes in <function>pg_get_expr()</> by disallowing it from being called with an argument that is not one of the system catalog columns it's intended to be used with diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml index 9ff4610ccfa..f426023896e 100644 --- a/doc/src/sgml/release-8.4.sgml +++ b/doc/src/sgml/release-8.4.sgml @@ -33,6 +33,43 @@ <listitem> <para> + Use a separate interpreter for each calling SQL userid in PL/Perl and + PL/Tcl (Tom Lane) + </para> + + <para> + This change prevents security problems that can be caused by subverting + Perl or Tcl code that will be executed later in the same session under + another SQL user identity (for example, within a <literal>SECURITY + DEFINER</> function). Most scripting languages offer numerous ways that + that might be done, such as redefining standard functions or operators + called by the target function. Without this change, any SQL user with + Perl or Tcl language usage rights can do essentially anything with the + SQL privileges of the target function's owner. + </para> + + <para> + The cost of this change is that intentional communication among Perl + and Tcl functions becomes more difficult. To provide an escape hatch, + PL/PerlU and PL/TclU functions continue to use only one interpreter + per session. This is not considered a security issue since all such + functions execute at the trust level of a database superuser already. + </para> + + <para> + It is likely that third-party procedural languages that claim to offer + trusted execution have similar security issues. We advise contacting + the authors of any PL you are depending on for security-critical + purposes. + </para> + + <para> + Our thanks to Tim Bunce for pointing out this issue (CVE-2010-3433). + </para> + </listitem> + + <listitem> + <para> Prevent possible crashes in <function>pg_get_expr()</> by disallowing it from being called with an argument that is not one of the system catalog columns it's intended to be used with |