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