Re: Potential security risk associated with function call - Mailing list pgsql-hackers

From Nico Williams
Subject Re: Potential security risk associated with function call
Date
Msg-id abBEn4mwC5SGA9Mw@ubby
Whole thread Raw
In response to Re: Potential security risk associated with function call  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Potential security risk associated with function call
Re: Potential security risk associated with function call
List pgsql-hackers
On Tue, Mar 10, 2026 at 09:23:50AM -0400, Robert Haas wrote:
>                        [...]. The example that started this thread is
> essentially unpreventable, because we need CREATE FUNCTION to be
> possible and we need the superuser to tell us what the C code is
> expecting, but the number of people who go tinkering with catalog
> contents manually without fully understanding the consequences seems
> to be much larger than I would have thought, even if the tinkering is
> usually less dramatic than this example.

If DWARF is available you could always get the C function's
prototype from that, and sanity-check it.  But DWARF really bloats
shared objects, and it's not universal, so it's not a good solution.

C is just a crappy language.  You play with fire, you best know what
you're doing -- that's a reasonable policy.  And since PG is written in
C, and users do have C-coded extensions here and there, playing with
fire has to be supported.

It'd be clever if there was at least a standard for a subset of DWARF
that provides just the types information (but not, e.g., stack
unwinding) so that we could have some sort of standard reflection
support in C.  That would be for the C standards committee.

Nico
-- 



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Corey Huinker
Date:
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions