Itagaki Takahiro wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
>
>>>>> ==== Internal structures ====
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
>>
>> In SELinux model, massive number of objects shares a limited number of
>> security context (e.g more than 100 tables may have a same one), this
>> design (it stores "security label OID" within the tuple header) is well
>> suitable for database objects.
>
> What plan do you have for system columns added by the patch
> (datsecon, nspsecon, relsecon, etc) after we have securty_id
> system column? Will we have duplicated features then?
In my plan, these fields will be removed when we add security system
column support.
> Even if system tables don't use security_id columns, should the data type
> of *secon be oid instead of text? I think pg_security described in the wiki
> page is useful even if we only have object-level security.
> How about adding pg_security and changing the type of *secon to oid?
The reason why the current version stores security context in plain
text is to minimize the scale of changeset as I have been pointed out
many times for a long time. :(
The pg_security catalog support requires about additional 1KL to the
current patch. It seems to me it goes against to the previous suggestions.
-- keep it smaller, and step-by-step enhancement
BTW, If you don't have any complaints about new syntax in CREATE TABLE
statement, I'll revise the patch soon.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>