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
- v4-0001-Introduce-new-control-file-parameter-protected-to-de.patch (application/octet-stream) patch v4-0001
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.