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

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().

>>> Actually, you called it "sepostgresql_mode", SE*, but how are we going
>>> to control the SQL-level row permissions? Are we using this name? I
>>> didn't think so because it seems so associated withe SE-Linux, and if
>>> not, how would one say whether a table has SQL-level row permissions?
>> A new GUC variable of "row_acl_is_enabled" allows us to toggle the SQL-level
>> row permission feature, when the binary is built with "--enable-row-acl".
>
> I assumed we would always enable SQL-level row permissions. Why would
> it be a compile-time option?

The SQL-level row permission feature is implemented as a guest of PGACE
security framework, so we need to select one of the guest mehanism when
compile-time.
The "--enable-selinux" and "--enable-row-acl" are exclusive option.

>> In my guess, I'll be able to complete to put a flag within TupleDesc to
>> control security field of HeapTupleHeader by tomorrow. And I have a plan
>> to check its behavior in this weekend before merge them into my tree.
>
> Nice. I will look over your newest version as soon as I can.

Today, I could complete to implement the newer version which passes
standard regression tests except for two cases expected.

Simon,
In the result of "pgbench -i -s 10", the "sepostgresql_row_level=true"
case consumed 152MB of storage, and the "sepostgresql_row_level=false"
case consumed 148MB of storage.

[kaigai(at)saba sepgsql]$ du -hs $PGDATA/base/16384
152M /opt/sepgsql/base/16384
[kaigai(at)saba sepgsql]$ du -hs $PGDATA/base/16385
148M /opt/sepgsql/base/16385

Now I'm under preparation to submit the newest patch set.
ToDo:
- Check behavior for SE-PostgreSQL specific operations.
(like security context updates)
- Implementation of new table options to disable row-acl.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>