security hook on table creation
От | KaiGai Kohei |
---|---|
Тема | security hook on table creation |
Дата | |
Msg-id | 4C7EF1EE.4030609@ak.jp.nec.com обсуждение исходный текст |
Ответы |
Re: security hook on table creation
|
Список | pgsql-hackers |
This patch allows external security providers to check privileges to create a new relation and to inform the security labels to be assigned on the new one. This hook is put on DefineRelation() and OpenIntoRel(), but isn't put on Boot_CreateStmt, create_toast_table() and make_new_heap(), although they actually create a relation, because I assume these are the cases when we don't need individual checks and security labels. DefineIndex() also creates a new relation (RELKIND_INDEX), but it seems to me the PG implementation considers indexes are a part of properties of tables, because it always has same owner-id. So, it shall be checked at the upcoming ALTER TABLE hook, instead. The ESP plugins can return a list of security labels of the new relation, columns and relation-type. If multiple ESPs are installed, it shall append its security labels on the security labels of the secondary plugin. The list shall be a list of SecLabelItem as follows: typedef struct { ObjectAddress object; const char *tag; const char *seclabel; } SecLabelItem; OID of them are decided in heap_create_with_catalog(), so ESP cannot know what OID shall be supplied at the point where it makes access control decision. So, the core routine fix up the SecLabelItem::object->objectId later, if InvalidOid is given. I think it is a reasonable idea rather than putting one more hook to store security labels after the table creation. Please also note that this patch depends on the security label support patch that I submitted before. Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com>
Вложения
В списке pgsql-hackers по дате отправления: