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

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

> 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".
In this case, the "sepostgresql_*" are enclosed by #ifdef HAVE_SELINUX, so
these are not available.

>>> On a related note, KaiGai, you are now starting the long road of getting
>>> feedback with the ultimate goal of getting your patch into CVS. I will
>>> warn you that there is often much work during this stage, and it might
>>> stretch into January as we request adjustments, but ultimately your
>>> feature and Postgres will be better for it. Thanks for sticking with
>>> it.
>> Don't worry, I'm be available for the works, and give a lot for inclusion
>> of the feature at v8.4.
>
> Great. Sometimes these bold additions can require perhaps thirty
> changes before they are added to CVS, I am afraid to say. It can be a
> painful part of open source development, even though in the end it is
> worth it. (While it is happening, it doesn't seem very useful.)

s/painful/dynamic/g :-)

If you can ready to post some of comments, earlier is happier for me.
It is unclear for me when the CommtiFest:Nov is finished, but it is sure
we don't have enough days.

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.

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