Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

KaiGai Kohei wrote:
> > What I am saying is for the default compile, SQL-level ACLs should be
> > possible because, since the ACL field has optional storage, there is no
> > downside to have it be available by default.
> 
> I think it is a possible and desirable desicion from the viewpoint of
> security folks.
> 
> However, I think we have a few issues, and it makes unclear whether
> we can make an agreement in the community.
> The one is a cost of security hooks. They consume a bit more CPU steps
> when a security mechanism is enabled. The other is prevention to override
> a few hooks (ExecutorRun_hook and planner_hook), because they assume
> standard implementations to be executed.
> 
> Which is more desirable option in the default?

Well, my assumption is that if a table doesn't have SQL-level row
permissions then there is no overhead becaues there are no permissions
to check.  If it does have  SQL-level row permissions then the user who
created the table has accepted the performance impact of SQL-level row
permissions.  I would think it would be pretty easy to see quickly if
any table in a query has SQL-level row permissions and then take the
performance hit.

For example, I might want to put SQL-level row permissions on an audit
table, but none of my other tables, and in that case I assume there is
only a performance impact on queries that use the audit table.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +