Skip site navigation (1) Skip section navigation (2)

security hook on table creation

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 (view raw or flat)
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: pgsql-table-creation.1.patch
Description: text/x-patch (10.7 KB)

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-09-02 00:57:43
Subject: Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression
Previous:From: Tom LaneDate: 2010-09-02 00:12:27
Subject: Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group