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. +
