KaiGai Kohei wrote:
> 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.
Yes. It is good to have SQL-level row security available by default in
every binary, even if it requires a few checks in C.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
