Re: Potential security risk associated with function call

On Tue, Mar 10, 2026 at 12:19 PM Nico Williams <nico(at)cryptonector(dot)com>
wrote:

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

I'm really tired of "C" bashing. The C programming language is a tool.
Effective and powerful tools can be dangerous, but the productivity is
worth it. The problem isn't the "C" language, it is with people who try to
program in C but do not know C.

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

Why do we need that?

> Nico
> --
>
>
>