Re: [HACKERS] Not quite a security hole: CREATE LANGUAGE for non-superusers

2012-05-30 Thread Tom Lane
Noah Misch writes: > I wondered about ALTER FUNCTION SET guc = '...' and tried to test it: > CREATE FUNCTION f(out ret text) RETURNS text LANGUAGE plpgsql AS > 'BEGIN ret := current_setting(''work_mem''); END'; > ALTER FUNCTION plpgsql_call_handler() SET work_mem = '2MB'

Re: [HACKERS] Not quite a security hole: CREATE LANGUAGE for non-superusers

2012-05-30 Thread Noah Misch
On Wed, May 30, 2012 at 12:02:06PM -0400, Tom Lane wrote: > One thing the owner *can* do is use ALTER FUNCTION to change secondary > properties of the function, such as strictness, volatility, SECURITY > DEFINER, etc. So far as I can see, none of these properties are examined > for a PL support fu

[HACKERS] Not quite a security hole: CREATE LANGUAGE for non-superusers

2012-05-30 Thread Tom Lane
We allow non-superuser database owners to execute CREATE LANGUAGE for a trusted language (one marked as tmpldbacreate in pg_pltemplate). Currently, the C-language support functions for the language end up owned by that non-superuser. This is on the hairy edge of being a security hole, since genera