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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
