To: ljb <lbayuk@mindspring.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Is PQfn() insecure or not? 
In-reply-to: <autddu$2uri$1@news.hub.org> 
References: <autddu$2uri$1@news.hub.org>
Comments: In-reply-to ljb <lbayuk@mindspring.com>
	message dated "Wed, 01 Jan 2003 00:40:31 +0000"
Date: Wed, 01 Jan 2003 14:22:49 -0500
Message-ID: <7477.1041448969@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

ljb <lbayuk@mindspring.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