From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org, Jan Wieck <jan@wi3ck.info>
Subject: Re: I propose killing PL/Tcl's "modules" infrastructure
Date: Sun, 26 Feb 2017 14:54:42 -0500
Message-ID: <18606.1488138882@sss.pgh.pa.us> (raw)
In-Reply-To: <45faa542-212a-5225-2b62-c80a8df2d0fd@2ndQuadrant.com>
References: <22067.1488046447@sss.pgh.pa.us>
<234c68e3-47ee-4db1-fe6d-6a5de56575b6@2ndQuadrant.com>
<23184.1488048288@sss.pgh.pa.us>
<33fe0208-74df-1a03-08af-9a4f0d1ed14d@2ndQuadrant.com>
<24478.1488050485@sss.pgh.pa.us>
<45faa542-212a-5225-2b62-c80a8df2d0fd@2ndQuadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> [ we should borrow plv8's start_proc idea for pltcl ]
So after thinking about this for awhile, I propose the following
concrete spec for replacing pltcl's autoload-unknown behavior:
* Invent two GUCs, pltcl.start_proc and pltclu.start_proc, which default
to empty strings but can be set to the name (possibly schema-qualified)
of a parameterless function that must be of the corresponding language.
When so set, the specified function is called once just after creation of
any pltcl or pltclu interpreter.
* The function is called as the current SQL user, who must have
permissions to call it. (This decision is more or less forced by
the fact that pltcl interpreters are per-userid; we want whatever
initialization gets done to be done in the new interpreter, and it
would be very weird and probably a security hole if we weren't
running as the same SQL userid that owns the interpreter.)
* Pre-call error conditions (no such function, wrong language, or no
permissions) result in a WARNING but the original operation continues.
(Making these WARNING not ERROR is possibly debatable, but it looks
like that's what plv8 does.)
* If the function itself throws an error, we do a transaction abort,
but the Tcl interpreter remains in existence and is deemed usable
for later operations. So a failing start_proc can't lock you out
of pltcl operations altogether.
* I'm not terribly comfortable about what the permissions levels of the
GUCs ought to be. The call permissions check means that you can't use
either GUC to call a function you couldn't have called anyway. However
there's a separate risk of trojan-horse execution, analogous to what a
blackhat can get by controlling the search_path GUC setting used by a
SECURITY DEFINER function: the function might intend to invoke some pltcl
function, but you can get it to invoke some other pltcl function in
addition to that. I think this means we had better make pltclu.start_proc
be SUSET, but from a convenience standpoint it'd be nice if
pltcl.start_proc were just USERSET. An argument in favor of that is that
we don't restrict search_path which is just as dangerous; but on the other
hand, existing code should be expected to know that it needs to beware of
search_path, while it wouldn't know that start_proc needs to be locked
down. Maybe we'd better make them both SUSET.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, jan@wi3ck.info
Subject: Re: I propose killing PL/Tcl's "modules" infrastructure
In-Reply-To: <18606.1488138882@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox