Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Ashutosh Sharma <ashu.coek88@gmail.com>

From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, John H <johnhyvr@gmail.com>, Alexander Kukushkin <cyberdemn@gmail.com>, Jelte Fennema-Nio <postgres@jeltef.nl>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-24T12:28:35Z
Lists: pgsql-hackers

Attachments

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.