From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jan Wieck <jan(at)wi3ck(dot)info> |
Subject: | Re: I propose killing PL/Tcl's "modules" infrastructure |
Date: | 2017-02-27 06:53:04 |
Message-ID: | CA+Tgmoa5R2__OLUVm2jLj1NEL3Cj5gZbmkvJPmQXyWQdSZUrEQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 27, 2017 at 1:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-02-27 06:53:35 | Re: Creation of "Future" commit fest, named 2017-07 |
Previous Message | Robert Haas | 2017-02-27 06:51:38 | Re: Enabling parallelism for queries coming from SQL or other PL functions |