[HACKERS] minor feature request: Secure defaults during function creation
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. Thanks, Pascal Meunier Purdue University CERIAS ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] minor feature request: Secure defaults during function creation
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
Re: [HACKERS] minor feature request: Secure defaults during function creation
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
