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

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Дата
Msg-id 20120612153103.GB6035@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jun 11, 2012 at 11:03:10PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: 9.2 final