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
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 |