From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | PgSQL-Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | security hook on table creation |
Date: | 2010-09-02 00:38:06 |
Message-ID: | 4C7EF1EE.4030609@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)ak(dot)jp(dot)nec(dot)com>
Attachment | Content-Type | Size |
---|---|---|
pgsql-table-creation.1.patch | text/x-patch | 10.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-09-02 00:57:43 | Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression |
Previous Message | Tom Lane | 2010-09-02 00:12:27 | Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression |