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

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 <kaigai@kaigai.gr.jp>