Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely - Mailing list pgsql-docs

From Bruce Momjian
Subject Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely
Date
Msg-id Yvvw1JB/Y12HvAYn@momjian.us
Whole thread Raw
In response to SQL-standard function bodies and creating SECURITY DEFINER routines securely  (Erki Eessaar <erki.eessaar@taltech.ee>)
Responses Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely
Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely
List pgsql-docs
On Sat, Dec 25, 2021 at 02:36:27PM +0000, Erki Eessaar wrote:
> 
> Hello
> 
> PostgreSQL 14 added the feature: "Allow SQL-language functions and procedures
> to use SQL-standard function bodies."
> 
> If I understand correctly, then in this case the system  will track
> dependencies between tables and routines that use the tables. Thus, the
> SECURITY DEFINER routines that use the new approach do not require the
> following mitigation, i.e., SET search_path= is not needed. The following part
> of documentation does not mention this.
> 
> https://www.postgresql.org/docs/current/sql-createfunction.html#
> SQL-CREATEFUNCTION-SECURITY
> 
> [elephant] PostgreSQL: Documentation: 14: CREATE FUNCTION
>            Overloading. PostgreSQL allows function overloading; that is, the
>            same name can be used for several different functions so long as
>            they have distinct input argument types.Whether or not you use it,
>            this capability entails security precautions when calling functions
>            in databases where some users mistrust other users; see Section
>            10.3.. Two functions are considered the same if they have the same
>            ...
>            www.postgresql.org

I have written the attached patch to mention this issue about sql_body
functions.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson


Attachment

pgsql-docs by date:

Previous
From: "Marc M."
Date:
Subject: Re: Lower or Upper case for F.33. pg_trgm
Next
From: Tom Lane
Date:
Subject: Re: SQL-standard function bodies and creating SECURITY DEFINER routines securely