From: | John H <johnhyvr(at)gmail(dot)com> |
---|---|
To: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
Cc: | Ashutosh Sharma <ashu(dot)coek88(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-12 18:05:33 |
Message-ID: | CA+-JvFu28RhGyeMHoOYxa3tVhtiaWxfhA=cdXOFRvo=krZHGdg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 that an 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-06-12 18:08:02 | Re: Proposal for Updating CRC32C with AVX-512 Algorithm. |
Previous Message | Robert Haas | 2024-06-12 17:56:23 | Re: Improve the granularity of PQsocketPoll's timeout parameter? |