Itagaki Takahiro wrote:
KaiGai Kohei <kai...@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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
