| 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: | Whole Thread | Raw Message | 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 |