Re: [HACKERS] minor feature request: Secure defaults during function creation

[Tom Lane]

"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Sep 14, 2006 at 10:24:43AM -0400, Pascal Meunier wrote:
>> My request is to allow changing default permissions for function creation, a
>> la "umask", or at least not give PUBLIC execute permissions by default.

> Hrm... do we have any other objects that default to granting permissions
> on creation?

Yes; see the GRANT reference page.

I'm disinclined to change it.  We've had the current behavior since we
introduced ACLs for functions at all, and there have been very few
complaints.  I think we'd get a lot more complaints if we denied public
EXECUTE by default.  One reason is that given the way pg_dump and
default permissions work, any such change would break existing
applications, because an existing schema loaded into a new backend
would suddenly have different permissions behavior.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] minor feature request: Secure defaults during function creation

[Jim C. Nasby]

On Thu, Sep 14, 2006 at 10:24:43AM -0400, Pascal Meunier wrote:
> First, I asked about this on #postgresql, and I realize that this request
> would be a low priority item.  Yet, it would be an improvement for security
> reasons.
> 
> When creating a function using EXTERNAL SECURITY DEFINER, by default PUBLIC
> has execute privileges on it.  That's unexpected given that when I create a
> new table, PUBLIC doesn't have any privileges on it.  It's also not a secure
> default.
> 
> My request is to allow changing default permissions for function creation, a
> la "umask", or at least not give PUBLIC execute permissions by default.  I
> am aware that it is possible to wrap the create function statement with the
> necessary grants/revokes inside a transaction, as a work-around, but it is
> not obvious and makes things unnecessarily inconvenient.  This increases the
> chances of beginner and even medium-skill admins to get their security
> wrong.

Hrm... do we have any other objects that default to granting permissions
on creation? ISTM all objects should be created with no permissions.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org