Re: SE-PgSQL patch review
От | KaiGai Kohei |
---|---|
Тема | Re: SE-PgSQL patch review |
Дата | |
Msg-id | 4B0CFF14.6060201@kaigai.gr.jp обсуждение исходный текст |
Ответ на | Re: SE-PgSQL patch review (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: SE-PgSQL patch review
|
Список | pgsql-hackers |
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>
В списке pgsql-hackers по дате отправления: