Simon Riggs wrote: >>> I would also like to see the feature part of normal Postgres, rather >>> than as a compile time option. The per-row overhead would then be >>> optional, just as WITH OIDS is optional. This would allow many >>> applications to take advantage of row level security, without the need >>> for switching to a different executable and without the need to enable >>> it for every table. For high security applications, default_row_security >>> = on would obviously be a requirement. With a single executable on all >>> distros we will have more robust software and it will be easier to >>> configure and use. >> An issue is who can enable or disable the row-level security option. >> If the owner of table can do it discretionary, we don't call it a >> "mandatory" access control feature. > > It seems fairly easy to do that with a GUC, or at least an option on > CREATE DATABASE, with no equivalent ALTER DATABASE option. Once created > with security, a table would not be able to turn off security. So nobody > would be able to turn off security for existing data.
SE-PostgreSQL already has a GUC option to enable/disable the feature, so I don't think a GUC option to control features is not a strange idea. In fact, I also had considered an option to disable the row-level access control feature in the similar way, when I got a comment that platform independent row-level security is a prerequisite to merge SE-PostgreSQL. However, I made a decision to implement the "rowacl" feature, not a new GUC option to disable row-level security. I had two reasons why I didn't implement the option. The first is the relationship between table/column-level access controls and row-level controls on system catalogs is unclear. For example, SE-PostgreSQL handles DELETE on pg_class as an operation to drop table, because it has same meanings. The table-level access controls break down, if only row-level checks are disabled. The other is an issue on implementation. Even if row-level security is disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject has to hold its security context, because it means the security context of tables, columns, procedure and largeobjects. However, the length of a tuple is computed at heap_form_tuple(), and its arguments don't contains the object id of relation. Thus, we cannot make a decision whether the newly created tuple should have a security field, or not. The heap_form_tuple() is invoked from 60 of functions. It might be possible to change all the argument list to deliver relation id. But it seems to me excess updates for the purpose. Thus, I recommend you to assign uniformed security context whole of the table. The default security policy allows all the clients to operate anything on tuples labeled as "sepgsql_table_t" except for relabeling them. (BTW, it is a default type when here is no special configuration.) 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
