Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)

On Mon, Jun 11, 2012 at 11:03:10PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> >> CREATE FUNCTION + ALTER FUNCTION OWNER TO is useful for creating another
> >> user's untrusted-language SECURITY DEFINER function. ALTER FUNCTION CALLED ON
> >> NULL INPUT ought to require that the user be eligible to redefine the function
> >> completely.
>
> > Here's a patch implementing that restriction. To clarify, I see no need to
> > repeat *all* the CREATE-time checks; for example, there's no need to recheck
> > permission to use the return type. The language usage check is enough.
>
> This seems bizarre and largely unnecessary. As you stated to begin
> with, granting ownership of a function implies some degree of trust.

Yes, but I would never expect that level of trust to include access to crash
the server as a consequence of the function's reliance on STRICT.

> I do not want to get into the business of parsing exactly which variants
> of ALTER FUNCTION ought to be considered safe.

Fair concern.

> And I definitely don't
> want to add a check that enforces restrictions against cases that have
> got nothing whatever to do with C-language functions, as this patch
> does.

We don't have a principled basis for assuming that this hazard cannot apply to
third-party untrusted languages. We could add another pg_language flag to
make the distinction for languages like plperlu. They're untrusted by virtue
of granted access beyond the database, but no mismatch between the function
definition and the function implementation can crash the server or similar.
Adding such a thing at this point seems excessive to me.