Re: Per-function search_path => per-function GUC settings - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Per-function search_path => per-function GUC settings
Date
Msg-id 1188757746.4144.74.camel@jdavis
Whole thread Raw
In response to Re: Per-function search_path => per-function GUC settings  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Kenneth Marshall
Date:
Subject: Hash index todo list item
Next
From: "Kevin Grittner"
Date:
Subject: Re: Attempt to stop dead instance can stop a random process?