On Tue, Jun 12, 2012 at 03:13:26PM -0400, Tom Lane wrote:
> Even if I accepted that premise, this patch is a pretty bad
> implementation of it, because it restricts cases that there is no
> reason to think are unsafe.
>
> A less bizarre and considerably more future-proof restriction, IMO,
> would simply refuse any attempt to give ownership of a C function
> to a non-superuser.
That just moves the collateral damage to a different set of victims.
Hardcoding the list of vulnerable languages isn't so "future-proof". I'd
otherwise agree in principle if we were designing a system from scratch, but
it doesn't fit with the need to harmoniously protect existing systems. Adding
this restriction now would make some existing databases fail to restore from
dumps. That is grave enough at any juncture, let alone for a backpatched fix.
On Tue, Jun 12, 2012 at 04:14:48PM -0400, Tom Lane wrote:
> Basically, if we go down the road Noah is proposing, I foresee a steady
> stream of security bugs and ensuing random restrictions on what function
> owners can do. I do not like that future.
Then let's have every ALTER FUNCTION require the same language usage check as
CREATE FUNCTION. Or, if you insist, do so only for the hardcoded cases of
INTERNALlanguageId and ClanguageId, and document that no third-party PL may
rely on STRICT to the extent they do. This of course forbids more than
necessary but still strictly less than your proposal of blocking the original
ownership change.
nm
