Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

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 <kaigai(at)kaigai(dot)gr(dot)jp>