Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

From: John H <johnhyvr(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Jeff Davis <pgsql(at)j-davis(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date: 2024-06-19 00:36:35
Message-ID: CA+-JvFtkZ478qTpkFp=-HbhxiK4juOXqd-rG4GCvWg54AWAQkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Ashutosh,

Thanks for clarifying.

> not standalone functions created independently

I'm wondering why we wouldn't want to extend that functionality so
that if users (including superusers) do want to automatically
configure search_path
when they're creating functions it's available.

> The difference is that installing extensions typically requires superuser privileges,
> which is not the case with standalone functions.

Yes, but inadvertent access to different roles can still occur even if
it's not a superuser.

It's not clear to me who the audience of this commit is aimed at,
cause I see two sort of
different use cases?

1. Make it easier for extension authors to configure search_path when
creating functions

The proposed mechanism via control file makes sense, although I would
like to understand
why specifying it today in CREATE FUNCTION doesn't work. Is it an
awareness issue?
I suppose it's easier if you only need to set it once in the control file?
Is that ease-of-use what we want to solve?

2. Make it easier to avoid inadvertent escalations when functions are created
(e.g CREATE EXTENSION/CREATE FUNCTION)

Then I think it's better to provide users a way to force the
search_path on functions when
extensions are created so superusers aren't reliant on extension authors.

Thanks,

--
John Hsu - Amazon Web Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-06-19 00:43:36 Re: allow changing autovacuum_max_workers without restarting
Previous Message Andreas 'ads' Scherbaum 2024-06-18 22:40:52 Re: Proposal: Document ABI Compatibility