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

Reply via email to