Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions - Mailing list pgsql-hackers

From Ashutosh Sharma
Subject Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date
Msg-id CAE9k0Pn1MzActPJPVAr4gFphre11LLcY_mkmXD3pCB4uRRp=yQ@mail.gmail.com
Whole thread Raw
In response to Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Ashutosh Sharma <ashu.coek88@gmail.com>)
List pgsql-hackers
Hi All,

Here is the v4 patch with the following new changes:

1) Now allows users to explicitly set search_path to $extension_schema.

2) Includes updates to the documentation.

3) Adds comments where previously absent.

Note: The new control file parameter is currently named as "protected"
which is actually not the precise name knowing that it just solves a
small portion of security problems related to extensions. I intend to
rename it to something more appropriate later; but any suggestions are
welcome.

Besides, should we consider restricting the installation of extensions
in schemas where a UDF with the same name that the extension intends
to create already exists? Additionally, similar restrictions can also
be applied if UDF being created shares its name with a function
already created by an extension in that schema? I haven't looked at
the feasibility part, but just thought of sharing it just because
something of this sort would probably solve most of the issues related
to extensions.

--
With Regards,
Ashutosh Sharma.

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [18] Policy on IMMUTABLE functions and Unicode updates
Next
From: Fujii Masao
Date:
Subject: Re: Add privileges test for pg_stat_statements to improve coverage