Re: I propose killing PL/Tcl's "modules" infrastructure

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Jan Wieck <jan@wi3ck.info>
Date: 2017-02-27T14:36:56Z
Lists: pgsql-hackers

On 02/26/2017 02:54 PM, Tom Lane wrote:
> * 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.
>

plperl's on_plperl_init and on_plperlu_init settings are both SUSET.

In practice with PLv8 this is usually set in the config file in my
experience.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Invent start_proc parameters for PL/Tcl.

  2. Remove PL/Tcl's "module" facility.

  3. Remove all of the libpgtcl and pgtclsh files, including all references to