Re: Is PQfn() insecure or not?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ljb <lbayuk(at)mindspring(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Is PQfn() insecure or not?
Date: 2003-01-01 19:22:49
Message-ID: 7477.1041448969@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

ljb <lbayuk(at)mindspring(dot)com> writes:
> "Programmer's Guide, Client Interfaces, libpq, The Fast-Path Interface"
> describes PQfn() and has this alarming remark:
> "This is a trapdoor into system internals and can be a potential
> security hole."
> Sure this isn't true. PQfn() just lets a frontend call a function which is
> also accessible (if maybe not useful) via a SELECT statement, correct?

The insecure part is not the function call per se (*); it's the fact
that the frontend feeds raw internal-format values to the backend for
the function's parameters. It'd be fairly trivial to cause a backend
crash by feeding bogus data. Not sure whether it's possible to do
anything worse than that.

One thing we should think about during the planned protocol redesign for
7.4 is whether to change fastpath to pass and return external-format
values. This would slow it down marginally, but would make it far safer
and more convenient to use ...

(*) Actually, I just noticed that the fastpath code fails to check whether
the user has permission to call this function, so as of 7.3 that could
be considered a security hole. It's an easily fixable one, though.

regards, tom lane

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message ljb 2003-01-01 21:57:13 Re: Is PQfn() insecure or not?
Previous Message ljb 2003-01-01 00:40:31 Is PQfn() insecure or not?