Re: [HACKERS] minor feature request: Secure defaults during
Thanks for answering; I appreciate it, as well as the efforts of all the people who contributed to this database that I now use in my projects. However, I feel that making a decision based on the number of prior and possible future complaints is a poor excuse to not do the right thing. A low number of prior complaints simply suggests lax security audits of default behaviors. I believe that the default object creation permissions described in the GRANT page are reasonable (The default is no public access for tables, schemas, and tablespaces; TEMP table creation privilege for databases; EXECUTE privilege for functions; and USAGE privilege for languages.), except when the EXTERNAL SECURITY DEFINER clause is used. That clause makes the functions take on setuid-like properties, so they should be handled cautiously. They shouldn't be given PUBLIC access by default. I asked MITRE to provide a CCE number for this issue (the CCE is a new effort like the CVE, but for configuration issues instead of vulnerabilities). I'll let you know if it happens. Regards, Pascal Meunier Purdue University CERIAS On 9/16/06 8:57 PM, Tom Lane [EMAIL PROTECTED] wrote: 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 5: don't forget to increase your free space map settings
Re: [HACKERS] minor feature request: Secure defaults during
On 9/18/06 2:00 PM, Tom Lane [EMAIL PROTECTED] wrote: Pascal Meunier [EMAIL PROTECTED] writes: I asked MITRE to provide a CCE number for this issue (the CCE is a new effort like the CVE, but for configuration issues instead of vulnerabilities). I'll let you know if it happens. Trying to force us to change things by getting Mitre involved is a really really good way to get pushback. I think you just killed any chance of getting this idea adopted. regards, tom lane Please forgive my chronic lack of tact, which is evident in my previous email; it is one of my flaws. I've been involved in the CVE for a long time, where the original idea was to give a number to every issue under discussion (including ones that aren't confirmed -- those were candidates), so getting a CCE number seemed a normal process to me. I also read your previous email as a likely dismissal, and did not want you to be surprised by seeing a CCE assigned to it. I'm sorry it offended you so much, regardless of the outcome. Moreover, I'd rather be a carpet to the PostgreSQL developers than be cited as the cause for a security improvement not being made, due to having antagonized so much the developers. Please, consider the issue and not the silly messenger. Sincerely, Pascal Meunier ---(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
[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
