Re: Potential security risk associated with function call

On Tue, 10 Mar 2026 at 17:19, 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.

Even with DWARF analysis it wouldn't help for C-language SQL
functions, as their signature is fixed: their one and only argument is
always just an FunctionCallInfo aka FunctionCallInfoBaseData*. That
struct then contains the actual arguments/argument count/nullability
info.

Also note that the "c" language here effectively only means
"dynamically loaded symbol using standard C linking with the
platform's C calling convention": PostgreSQL doesn't compile the
functions from sources. Any language that compiles to a binary that
links with such symbols should work; e.g. C++ and Rust are both using
this mechanism despite the "c" name used for the language.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)