Re: I propose killing PL/Tcl's "modules" infrastructure
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Jan Wieck <jan@wi3ck.info>
Date: 2017-02-27T06:53:04Z
Lists: pgsql-hackers
On Mon, Feb 27, 2017 at 1:24 AM, Tom Lane <tgl@sss.pgh.pa.us> 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. Making them SUSET sounds like a usability fail to me. I'm not sure how bad the security risks of NOT making them SUSET are, but I think if we find that SUSET is required for safety then we've squeezed most of the value out of the feature. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Invent start_proc parameters for PL/Tcl.
- 0d2b1f305dc7 10.0 landed
-
Remove PL/Tcl's "module" facility.
- 817f2a586342 10.0 landed
-
Remove all of the libpgtcl and pgtclsh files, including all references to
- 41fa9e9bae60 8.0.0 cited