Re: 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" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Jim C. Nasby" <jimn(at)enterprisedb(dot)com> 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
>