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

From Alvaro Herrera
Subject Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Date
Msg-id 1339535505-sup-5308@alvh.no-ip.org
Whole thread Raw
In response to Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Excerpts from Kevin Grittner's message of mar jun 12 17:08:09 -0400 2012:
> >Stephen Frost <sfrost@snowman.net> wrote:
>
> > If we had an independent way to have the function run as a
> > specific user, where that user DIDN'T own the function, I think
> > Kevin's use case would be satisfied.
>
> I agree.  I'm not sure quite what that would look like, but maybe
> SECURITY ROLE <rolename> or some such could be an alternative to
> SECURITY INVOKER and SECURITY DEFINER.  (I haven't looked to see
> what the standard has here.)

We talked briefly about this a year ago:
http://wiki.postgresql.org/wiki/PgCon_2011_Developer_Meeting#Authorization_Issues
(Not quite the same thing, but it's closely related).

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Next
From: Stephen Frost
Date:
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)