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

From John H
Subject Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date
Msg-id CA+-JvFu28RhGyeMHoOYxa3tVhtiaWxfhA=cdXOFRvo=krZHGdg@mail.gmail.com
Whole thread Raw
In response to Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Alexander Kukushkin <cyberdemn@gmail.com>)
Responses Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
List pgsql-hackers
Hi,

> I know about the problem and have seen the original email.

I'm sympathetic to the problem of potential privilege escalation when
executing functions. At the same time I'm not sure if there's that
much of a difference between 'CREATE EXTENSION' vs  superusers copying
a series of 'CREATE FUNCTION' where they don't understand these same
nuances.

CREATE FUNCTION already provides an ability to set the search_path. So
I'm wondering what the problem we want to solve here is. Is it that
there's too much friction for extension authors to have to set
search_path as part of the function definition and we want to make it
easier for them to "set once and forget"?


> But, I also agree with Jelte, it should be a property of a control file, rather than a user controlled parameter, so
thatan attacker can't opt out.
 

+1. Also curious what happens if an extension author has search_path
already set in proconfig for a function that doesn't match what's in
the control file. I'm guessing the function one should take
precedence.


--
John Hsu - Amazon Web Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Improve the granularity of PQsocketPoll's timeout parameter?
Next
From: Tom Lane
Date:
Subject: Re: Proposal for Updating CRC32C with AVX-512 Algorithm.