Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
Please consider SELinux/SE-PostgreSQL requires various kind of objects
(including database objects) to be labeled properly at the initial state.
If it allows clients to turn on row-level security feature, it means many
"unlabeled" tuples appear suddenly. In generally, these have to be labeled
before the system get being available.
I was thinking more about people are using the SQL-level row
permissions. Are they going to want it for all tables for all
databases, or not at all?
We don't have a reason why the SQL-level row permissions should be toggled
in global only. It it designed based on DAC policy, so it is quite natural
to be controled by owner of resources.
(However, it is not implemented yet.)
Yes, that was my question --- how will SQL-level row permissions be
controlled by the user.
When the given tuple has no ACL, it applies the default behavior which
allows anything for public. This behavior intends to keep compatible
works compared to the vanilla PostgreSQL.
We can have two state for "no ACLs". The first one is when tuples don't
have fixed 4-bytes security attributes. It can be happen when PostgreSQL
with SQL-level row-permissions mount compatible database files created
by vanilla PostgreSQL. The other is the fixed 4-byte security attribute
indicates an entry of "no ACLs". It seems unnecessary consumption, but
we cannot determine whether the user tries to set ACLs when heap_form_tuple().
One considerable solution is to add an RowACL specific table option to
disable row-level ACLs whole of the tables. It can be suitable for security
design because the option is provided by the resource owner.
For example:
CRATE TABLE t (
a int,
b text
) WITH (row_acl=disable);
If the reloptions contains an information to determine whether a new tuple
need the security field, or not, we can reflect it at heap_form_tuple().
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?
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
