Re: Potential security risk associated with function call

út 10. 3. 2026 v 19:09 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> > Tangent: I think it could be possible to make extensions (and PG
> > itself) generate more extensive pg_finfo records that contain
> > sufficient information to describe the functions' expected SQL calling
> > signature(s), which PG could then check and verify when the function
> > is catalogued (e.g. through lanvalidator).
>
> I think that'd be a lot of work with little result other than to
> change what sort of manual validation you have to do. Today, you
> have to check "does the function's actual C code match the SQL
> definition?". But with this, you'd have to check "does the function's
> actual C code match the pg_finfo record?". I'm not seeing a huge win
> there.
>
> Many many years ago when we first designed V1 function call protocol,
> I had the idea that we could write a tool that inspects C code like
>
> Datum
> int42pl(PG_FUNCTION_ARGS)
> {
> int32 arg1 = PG_GETARG_INT32(0);
> int16 arg2 = PG_GETARG_INT16(1);
> int32 result;
>
> and automatically derives (or at least cross-checks against) the SQL
> definition. And we probably still could write such a tool. But
> there's a large fraction of the code base where no attention was paid
> to following that layout, and/or one C function was made to handle
> several signatures by writing conditional logic to fetch the
> arguments. Maybe you could get an AI tool to disentangle such logic,
> but how much you wanna trust the results?
>
>
FmgrInfo holds fn_oid - so maybe it can holds proallargtypes too, and then
some assertation can be injected to PG_GETARG_X macros without massive
slowdown.

Regards

Pavel

> regards, tom lane
>
>
>