Bruce Momjian wrote:
> 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.
When the binary is built with the SQL-level row permissions and scanned
table does not activated it, all it does is checking a flag variable
at Relation->rd_options. I guess it will be acceptable cost.
In this case, DBA disables row-level permission on the table, so
no additional security field is required.
> 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.
It is not a zero, but tiny as far as we can ignore it in my opinion.
Thanks.
--
KaiGai Kohei <kaigai@kaigai.gr.jp>