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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers