Re: Per-function search_path => per-function GUC settings

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per-function search_path => per-function GUC settings
Date: 2007-09-02 18:29:06
Message-ID: 1188757746.4144.74.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2007-09-01 at 13:55 -0400, Tom Lane wrote:
> You already have that issue with respect to the default public execute
> permissions on the function. The standard solution is to do it in a
> transaction block --- then no one can even see the function until you
> commit.

It might be a good idea to have the ability to revoke privileges at
CREATE FUNCTION time also.

That could clutter up the CREATE FUNCTION syntax, but would offer an
opportunity to document the danger of default public execute in a
SECURITY DEFINER function.

Something like:
CREATE FUNCTION ...
LANGUAGE plpgsql
SECURITY DEFINER
REVOKE EXECUTE FROM PUBLIC;

Even if we don't do that, we should at least document your standard
solution here:
http://www.postgresql.org/docs/8.2/static/sql-createfunction.html

It is already documented here:
http://www.postgresql.org/docs/8.2/static/sql-grant.html

But the CREATE FUNCTION page has a section titled "Writing SECURITY
DEFINER Functions Safely", so I think it's useful to have it there, too.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2007-09-02 20:20:14 Re: Attempt to stop dead instance can stop a random process?
Previous Message Kenneth Marshall 2007-09-02 18:04:04 Hash index todo list item