Re: Potential security risk associated with function call

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
--